On 10/12/2012 08:41 AM, Liu Binsheng wrote:
> vec.cpp contains 1 includes.
> Unknown Includes: 0
> Unparsed Includes: 1
> Parsed Includes: 0
>
> A likely cause of an unfound tag is missing include files.
> The following includes were not found:
> vector
[...]
> --end--
>
> Obviously the header<vector> is /usr/include/c++/4.7/vector. I don't
> know why semantic said vector was not found.
>
> I also tried to trace semantic-fetch-tags by running
> semantic-force-refresh. And it seemed that vector was found.
It looks like it knows about your include, but didn't bother parsing it.
Unparsed includes are include files where it knows where it is, but
didn't bring it it.
What it does is controlled with the variable:
semanticdb-find-default-throttle
which needs to include 'system' so it will pull in your system headers.
That is there by default, so I'm not sure why it would be different
for you.
I use global-semantic-idle-scheduler-mode, which is in by default for
semantic-mode if you use Emacs integrated CEDET. That tends to make
sure misc headers and typecaches are built and ready to go when you need
them.
Are all those things enabled for you?
Eric

Liu Binsheng writes:
> Include Path Summary:
>
> The system include path is:
> /usr/include
> /usr/lib/gcc/i486-linux-gnu/4.7/include/
> /usr/local/include/
> /usr/lib/gcc/i486-linux-gnu/4.7/include-fixed/
> /usr/include/i386-linux-gnu/
> /usr/include/
> /usr/include/c++/4.7/
> /usr/include/c++/4.7/i486-linux-gnu/
> /usr/include/c++/4.7/backward/
>
>
> Include Summary: /home/chris/code/cpp/test/vec.cpp
>
> vec.cpp contains 1 includes.
> Unknown Includes: 0
> Unparsed Includes: 1
> Parsed Includes: 0
Could you please try the following: Put
(add-to-list 'magic-fallback-mode-alist '("^// " . c++-mode))
(add-to-list 'magic-fallback-mode-alist '("^#include" . c++-mode))
into your .emacs, delete everything in .emacs.d/semanticdb and try
again.
The long story:
Semantic should find the vector-include in the above paths, and I also
think it does. My guess is that the file 'vector' is not recognized as
being a C++ file, so the Semantic parser does not kick in.
As you know, the C++ STL includes do not have an extension (it's one of
those things only a committee could come up with, since it solves a
problem by creating bigger ones). The main issue is of course that Emacs
cannot easily see that this is a C++ file. The glibc STL has magic
comments like "-*- C++ -*-" in the first line (other STLs don't have
that, of course, since they couldn't care less about Emacs).
While you *are* using glibc, I recently experienced similar problems
which are probably due to some change in how those file-local variables
are handled in Emacs (their handling is notoriously difficult since they
can pose a security risk). To make things more complicated, Semantic
disables all kinds of stuff when loading files to speed things up; this
includes how file-local variables are handled (otherwise Emacs might ask
about them during load).
We need to properly fix that; the above is just a workaraound.
-David