>>> David Hansen <david.hansen@...> seems to think that:
>On Wed, 11 Jun 2008 22:11:54 -0400 Eric M. Ludlam wrote:
>
>> Thanks for the info and stack. According to the stack, I expect
>> that there are just lots of headers to include, and it appears that
>> EDE is getting involved with Webkit, as Webkit probably has
>> Makefile.am files in it.
>
>It's not related to WebKit, just a coincidence. This time i opened just
>a single .c file (apart from *scratch* no buffer that is of any interest
>for cedet) and cedet got again stuck while parsing GTK system headers.
>
>This file is not that complex:
>
>,----[ tst.c ]
>| #include <gtk/gtk.h>
>`----
>
>I can produce tons of stacktraces if you like, this happens reliable
>every time I lean back sipp some tea or smoke a cigarette. I'm not quit
>sure this would help.
I tried this (after cleaning up my semanticdb caches) and it went off
parsing stuff for a while, but it did not duplicate anything that I
could tell.
You can use:
M-x semantic-debug-idle-function
and
M-x semantic-debug-idle-work-function
to make it replicate the idle timer function.
The second time I ran the function in the sample file, it did nothing.
If you saw:
fontifying gtkwhatever.h (.......)
flickering up over an over, then that is likely because the parsing
statements from semantic put back whatever message was there before
the parse, not because it is re-fontifying anything.
Your messages buffer, though, had a cycle in it, so this may not be
the case.
[ ... ]
>> I'm not sure about the font-lock thing. I don't see it font-locking
>> messages when files are parsed in the background for me. I remember
>> trying to get it shut off, but don't see code for it in a quick
>> search. I can't disable all the file-init stuff since that is how
>> Semantic gets initialized so I can parse stuff.
>
>Not that I have the slightest idea how semantic works but can't you just
>initialize it and
>
>(with-temp-buffer (insert-file-contents file-name) (parse-it))
Ahh yes. I've fiddled with these things. If I do anything that
doesn't involve the regular find-file type activity that I don't
control wholely within CEDET, then I will eventually hit a file where
someone says "Hey, my file with some special hook I have didn't parse
correctly."
In addition, if I hand-run (c++-mode), or some other thing like that,
then it will still run c-mode-hooks, after-change-major-mode-hook, and
others, often initializing the thing I didn't want. Having the mode
active is required for all the buffer-local variables, and custom
hooks users need to control include path and parsing.
As an experiment, you could use:
semantic-before-idle-scheduler-reparse-hooks
and
semantic-after-idle-scheduler-reparse-hooks
to shut off/re-enable global-font-lock-mode, but I'd guess you'd hit
some other weirdness.
>Maybe something wrong with my config? I have to admit my emacs config
>is a big mess and a lot of try & error and guesswork:
>
>http://www.alice-dsl.net/david.hansen/cedet-cfg.el
[ ... ]
Your config is much more complex than I'd expect but seems ok. How do
you enable font-lock, and what version of Emacs are you running?
Eric
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net
|