>>> Alexander Syrov <asyrov@...> seems to think that:
>On Wed, 23 Mar 2005 10:14:06 -0500
>Eric M. Ludlam wrote:
> EML> First, I don't recommend a basic semantic systemdb for vast
> EML> quantities of source files. Even if you wait the multiple-days needed
> EML> to build the database, Emacs is forced to load the whole thing into
> EML> memory, and that would probably be a very sad thing.
>Well, IMVHO, this makes Semantic completion practically unusable. Even MS
>Visual Studio built-in IntelliSense feature works very quickly with all the
>system headers. Not to mention Visual Assist X addin. A pity that Emacs
>cannot provide the same level of convenience.
That fact is not lost on me. There is an extensive system for
creating semanticdb back-ends (of which semanticdb-system is one)
which allows you to implement a way to fetch or search tag lists
outside of Emacs. Emacs just isn't the right tool for very large
database tasks. Some day I would like to integrate ebrowse, or cscope
as the C/C++ back-end for system header files.
> EML> Instead, carefully choose a subset of system files you use a lot for
> EML> system databases. A small subset if possible.
>I write some code which uses Win32 API extensively. Most often, there
>is just one included header - <windows.h>, which in turn includes all the
>others, so no subset is possible. And of course I need completion for all
>the standard C library, STL (although Semantic cannot parse it correctly
>yet), some external libraries (e.g. Xerces). These are just very basic
> EML> You need to make sure that `semantic-default-c-path' is set to
> EML> something reasonable. I doubt it matches your cygnus include path.
> EML> Does this help?
>Thanks, this helped! Could not Semantic just initialize this variable from
>system INCLUDE enviroment variable?
I have never had this variable in my environment. Where does it come from.
>But now I'm facing other problems. Semantic seems to be unable to parse
>most of the system headers due to various macros present in them. E.g. the
>printf function is defined in stdio.h as follows:
>| int _EXFUN(printf, (const char *, ...));
> _EXFUN macro is defined in another header:
>| #define _EXFUN(name, proto) __cdecl name proto
>In my system database file I can find the following record:
>| ("_EXFUN" function (:prototype-flag t :arguments
>| (("" variable (:type ("printf" type (:type "class") nil nil)) ...
>It seems that Semantic didn't expand _EXFUN macro properly. That's why I
>lose most of the completions I need.
Macros will always be problematic because they enter the official
compiler in so many different ways. That is something I'm not sure
how to fix. I know many other code analyzers have the same problem.
I haven't worked on that problem much mostly because I would rather
spend time converting the GCC bison code to wisent to improve other
aspects of C++ parsing.
>Another problem is that Semantic doesn't show me any completion or prompt
>when I type function arguments (i.e. typed the opening brace and didn't
>type the closing one yet), as it cannot parse the incomplete code. But
>that's the very moment a prompt for argument names and types is needed most
>of all! And I want to get completion for function names which I use as
>arguments for another functions too.
>Can't it be fixed? (I suppose it can't, but that's very frustrating...)
The function the cursor is in needs to have been successfully parsed
at least once before code completion works. Once this is the case,
you can type an opening brace and the completion engine should get a
parse-update failure, and use the old cached values, but it does need
the old cached values to exist.
The success of that operation tends to be a little fragile at times.
It may have also gotten broken at some point recently.
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