CEDET

>>> David Engster <deng@...> seems to think that:
>I noticed that semantic fails to correctly parse system includes,
>e.g. lines like
>
>#include <cmath>
>
>get a red background after a while. Looking at 'cmath', I saw that it
>failed at
>
>#include <bits/c++config.h>
>
>which is in /usr/include/c++/4.3/i486-linux-gnu. So I added the
>following to my .emacs:
>
>(semantic-add-system-include "/usr/include/c++/4.3" 'c++-mode)
>(semantic-add-system-include "/usr/include/c++/4.3/i486-linux-gnu" 'c++-mode)
>
>Now, when I load any c++ file, the variable
>semantic-dependency-system-include-path is correctly showing those two
>paths. But when I fire up the idle work function, e.g. by calling
>semantic-debug-idle-work-function, the variable gets reset to
>
>("/usr/include" "/usr/include/c++/4.2.3")
>
>after the idle work function has finished. What makes this even more
>strange is that the latter path doesn't even exist on my system.
  [ ... ]

Hi,

Semantic will query your version of gcc by calling "gcc -v" and
parsing the output. I would assume it would show the above version
number 4.2.3.  Perhaps you compile with something not called "gcc"?

As I look in semantic-gcc.el, I see there is no configuration variable
for the path to gcc to change.  If you aren't using the default gcc,
we should add something so you can update what is being run yourself.

I'm not sure why your explicit configuration is being changed then
restored.  Do some of your headers start in c-mode instead of
c++-mode?  You may need to add your new headers to both modes?

I'm not sure how to debug a situation where a variable is being set to
some value in an unknown location.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

"Eric M. Ludlam" <eric@...> writes:
>>>> David Engster <deng@...> seems to think that:
>>Now, when I load any c++ file, the variable
>>semantic-dependency-system-include-path is correctly showing those two
>>paths. But when I fire up the idle work function, e.g. by calling
>>semantic-debug-idle-work-function, the variable gets reset to
>>
>>("/usr/include" "/usr/include/c++/4.2.3")
>>
>>after the idle work function has finished. What makes this even more
>>strange is that the latter path doesn't even exist on my system.

> Semantic will query your version of gcc by calling "gcc -v" and
> parsing the output. I would assume it would show the above version
> number 4.2.3.  Perhaps you compile with something not called "gcc"?

After some debugging, I noticed I still had old cruft in my c++-mode
which explicitly set those old system includes...  :-(

Sorry for the noise. Next time I better check my .emacs before posting...

But that leads me to another question: Do you think it would be a bad
idea to somehow override the (language)-mode hooks in
semantic-find-file-noselect? For example, I activate the HideShow minor
mode in my c/c++-mode-hooks, which slows down file parsing and also
overrides the progress bar with "Hiding Blocks ..." messages.

-David

>>> David Engster <deng@...> seems to think that:
  [ ... ]
>But that leads me to another question: Do you think it would be a bad
>idea to somehow override the (language)-mode hooks in
>semantic-find-file-noselect? For example, I activate the HideShow minor
>mode in my c/c++-mode-hooks, which slows down file parsing and also
>overrides the progress bar with "Hiding Blocks ..." messages.
  [ ... ]

I can't disable those, because that is also how the parsing
information is setup.  Does hideshow have a simple way of getting it
disabled again after the hooks run?  I suppose I could momentarily
override the function definition of it to make sure it can't get run.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

"Eric M. Ludlam" <eric@...> writes:
>>>> David Engster <deng@...> seems to think that:
>   [ ... ]
>>But that leads me to another question: Do you think it would be a bad
>>idea to somehow override the (language)-mode hooks in
>>semantic-find-file-noselect? For example, I activate the HideShow minor
>>mode in my c/c++-mode-hooks, which slows down file parsing and also
>>overrides the progress bar with "Hiding Blocks ..." messages.
>   [ ... ]
>
> I can't disable those, because that is also how the parsing
> information is setup. 

Yes. By "overriding" the hooks I meant something like


(let ((c-mode-hook 'semantic-default-c-setup)
      (c++-mode-hook 'semantic-default-c-setup)
      (emacs-lisp-mode-hook 'semantic-default-elisp-setup)
      (... likewise for the other hooks ...))
    [...]
     (find-file-noselect FILENAME)
  
> Does hideshow have a simple way of getting it disabled again after the
> hooks run?  I suppose I could momentarily override the function
> definition of it to make sure it can't get run.

There is 'turn-off-hideshow'. I tried calling that after the
find-file-noselect in semantic-find-file-noselect, but then I get the
message "Showing all blocks"... :-)

-David