It turns out that Emacs is not hung. It's just that the Makefile is
25k lines long, and it takes a really long time to parse. Your file
is so big, font lock won't touch it. Semantic won't break out because
the parse occurs in the imenu update. Errors in the imenu stuff will
often cause Emacs to exit.
I coded a timeout into the lexer which will safely bomb out of
lexing your mega makefile after 5 seconds. Sadly, the timeout check
adds 16% more time to every lexical operation, and it keeps blocking
input for 5 seconds every few moments. I replaced it with
`semantic-throw-on-input' instead which seems to enable C-g during
its phase. That added only 1.3%.
I found some inefficiencies in semantic-make-expand-tag, but fixing
that helped only a small bit. It just seems to take a really long
time to parse.
I found that the killer part (ie, no C-g control) was occurring due
to the imenu support. Imenu is perhaps the oldest semantic supported
tool file. It was still using the original parser functions. I
switched it to use `semantic-fetch-tags-fast' and suddenly C-g works
once the idle-timer goes off a moment later. I checked in this
I instrumented the parser and it is currently 33% through after
quite some time now. It takes about 1 second for the parser to
recover from each of the @COND_BLAH_BLAH@ lines. I added an lexical
analyzer for Make that strips them out, and that makes it go faster,
but the farther down the file it goes, the slower it gets. Some sort
of data growth issue.
Anyway, that's all I have for now. Hopefully the use C-g will
>>> Stephen Berman <Stephen.Berman@...> seems to think that:
>On Sun, 24 Jun 2007 16:29:43 +0200 Stephen Berman <Stephen.Berman@...> wrote:
>> On Wed, 29 Nov 2006 22:24:13 +0100 Stephen Berman <Stephen.Berman@...> wrote:
>>> I'm using current CVS cedet with the first Emacs 22 pretest tarball
>>> (GNU Emacs 18.104.22.168 (i686-pc-linux-gnu, GTK+ Version 2.8.10) of
>>> 2006-11-07 on escher). I've run across a file that causes Emacs to
>>> hang or loop infinitely when I try to visit it after loading cedet.
>>> There are two cases (both with emacs -Q):
>>> (i) Do M-: (load-file "<path to>/cedet/common/cedet.el") and then
>>> visit the file. The file gets loaded into a buffer but then Emacs
>>> immediately goes into a loop and consumes 100% CPU. The loop can be
>>> broken by C-g.
>>> (ii) Do M-: (load-file "<path to>/cedet/common/cedet.el"), then M-:
>>> (semantic-load-enable-code-helpers) and then visit the file. Emacs
>>> immediately hangs, consuming 100% CPU, without the file being visible
>>> in a buffer. C-g has no effect in this case, only kill -9.
>> I just determined that case (ii) still causes Emacs to hang
>> unbreakably. This is with CVS CEDET from 2007-05-02 under both the
>> released GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of
>> 2007-06-02 on escher as well as with CVS GNU Emacs 22.214.171.124
>> (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-06-03 on escher.
>> (Case (i) does not cause a hang with these versions. The file can be
>> downloaded at <http://article.gmane.org/gmane.emacs.cedet/2330/>.)
>Updated to current CVS CEDET and current CVS Emacs, and case (ii)
>still makes Emacs hang unbreakably.
[ ... ]
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net