>>> Nicolas Pernetty <nicopernetty@...> seems to think that:
>On Sun, 23 Oct 2005 20:15:24 -0400, "Eric M. Ludlam"
><eric@...> wrote :
>> >Semantic has a very interesting feature : when I first open a .c
>> >file, it opens all the headers included in this file to analyse them.
>> >But is it possible to configure it to open them 'in the background' ?
>> >That is to say to make the headers files don't appear in the buffer
>> >list after analysing ?
>> >When you open a .c file with a large number of headers, it's
>> >'cleaner' I think...
>> [ ... ]
>> The offending line is in semantic-analyze, specifically on line 127 I
>> think. I suspect it needs the file loaded so that searched tags can
>> find the associated buffer later. You could try changing that line
>> and seeing what happens.
>You were right, I tried to comment the line, and the headers files don't
>get opened anymore when I open a source file. It seems that it's
>'semanticdb-strip-find-results' who open all these files.
>Problem is that if these files don't get opened, semantic can't
>complete symbols anymore (because the symbol definition are in the
The last argument to semanticdb-strip-find-results specifies to open
the files. The strip-results call re-orders the tags. It is possible
to strip the results, but just not load the tags.
I am unclear what specifically you meant by 'comment the line' as you
may have been confused by my previous vague answer. If you did just
remove the last argument as I mention above, then we are in agreement,
and you confirmed my suspicion.
>Furthermore, if I try to complete with semantic-ia-complete-symbol,
>then all the headers files suddenly get opened again !
I'm not sure about that one. I used this to debug the previous:
M-x debug-on-entry RET find-file-noselect RET
(look at stack ...)
and then just figure out what semantic function leads to that call.
Be sure to use:
M-x cancel-debug-on-entry RET find-file-noselect RET
to turn that off.
>Is there a way to load them in the background without actually
>opening/displaying them ?
semanticdb does support accessing tag lists w/out loading the files.
In fact, that is what it was written for! The search routines also
support this, which is what the 'find-results' are.
Most of the tools using it work on tag lists, not semanticdb search
results, so the semanticdb stuff is stripped out. Once the stripped
lists are generated, the source location can get lost, which is why
the tools using it load the files in after the fact.
Anyway, that means the answer is "yes", but someone will need to
disable the loading (as you did above) and just work through finding
who needs the buffer information, and solving those problems one at a
Alternately, the use of semanticdb search results for all operations
could be used instead. This would probably be a better strategy.
Unfortunately, there may be some utility functions (like doc/comment
extractors) will still need the buffer loaded. I don't know which
ones those may be.
I am quite certain I will not have time for such a project until
sometime in December, so if you want to give it a try, that would be
spiffy, and I would assist when I can.
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org