>>> Jan Sacharuk <jan@...> seems to think that:
>On Wed, 18 Feb 2004 10:56:51 -0700, Jan Sacharuk <jan@...> wrote:
>> On Wed, 18 Feb 2004 12:36:24 -0500, Eric M. Ludlam
>> <eric@...> wrote:
>>> Actually, I kind of meant in your example to see if the case thing was
>>> the root of the problem, and not a red herring. If I can cobble
>>> together a reproducible case I can probably fix it. I'm guessing I
>>> need to use `file-truename' after initially finding the header. That
>>> would keep all references the same and allow lookups to work properly
>>> in the database.
>> Ah, I misunderstood. I'll try to eliminate at least one of the warnings
>> and get back to you about it.
>As a quick followup, I haven't gone through and performed this test, but I
>was wondering something. It appears that all the .h files that are being
>referenced are actually being OPENED. If I try to complete one variable
>name, it opens up a lot of .h files, and not just the ones that are
>included by the current file, but all the ones that can be reached by
>following the includes. Is this normal behaviour?
[ ... ]
The search routines now attempt to open the files mentioned by
include statements so that the scope of the area you are in is best
represented. I did have code in there at one time to recurse down
all include files, but turned it off because it was a bit
rambunctious. It will, however remember that you had visited that
file once upon a time, and not open it again, keeping track of the
tags that had been loaded. If those files were in a place you have
write access to, it will drop DB files so it won't need to reopen
those files in the future either.
It should not re-open the files over and over. That is bad, and I
don't know what the issue may be.
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