>>> Rui Tiago =?ISO-8859-1?Q?Ca=E7=E3o?= Matos <tiagomatos@...> seems to think that:
>I've been for some time now trying cedet's intellisense feature (which I
>think is the only sore point in emacs) from the pre3 release to a CVS
>version from some weeks ago. Still I haven't been able to get it to work
>(maybe my hopes are too high?).
>First I'd like to know to what extent are the instructions at  still
>valid with current CVS? The answer to this could be a basis to a revamp
>of that page which I'd be happy to do myself since I find the current
>page a little bit confusing. Maybe even remove mentions to beta versions
>and pre release versions that are quite old now anyway. BTW, patches for
>the site should be against the files at  right?
You are right, that page should be updated to remove references to old
versions, particularly the beta versions which really aren't relevant.
The stuff under the heading "In version 2.0 beta2 or later" is still
accurate if overly brief.
What isn't listed there are all the bits and pieces needed to tune
semantic so it can do completion within a project that involves more
than one directory. That is certainly something missing.
And yes, patches against the CVS version are best since the updating
the web site is just a "cvs up" command.
>Ok, I'll try to explain what my expectations of a _usable_ intellisense
>feature are. I'll assume only C use for now since that's what I'm most
>interested in and to keep things simple.
> * The setup should be brainded simple. For each project I'd like to be
>able to tell emacs to parse source files (both .c and .h including
>things like libc's headers) recursivelly begining at a set of roots.
>Even nicer if I could have some standard set and then be able to just
>extend that set for any given project (so to not always have to repeat
>things like /usr/include).
If a project uses EDE projects, or Automake, the EDE system will
automatically detect project roots. If you need to specify the roots
yourself, customize `semanticdb-project-roots', or write a function
Asking Emacs/semantic to parse all source files in a project can take
a long time. I remember waiting an hour just to get through one
directory in /usr/include before deciding that was not the best
I had intended to use ebrowse for a long time to make a fast parsing
backend for semanticdb engine. Thankfully, Joakim finally did the
research to make that happen. See the commentary in
semanticdb-ebrowse for the basics there.
Currently missing is the "automatic" and "recursive" parts. After
reading a bunch on this topic on Emacswiki, I've started looking into
how to make the ebrowse back end do this. To start, I made it only
parse header files since that's all that is needed for completion.
> * Emacs should keep these databases somewhere so to not have to reindex
>things at each new run and should be smart enough to reindex files that
>have changed since last indexing .
Semanticdb, and semanticdb-ebrowse both do this, though ebrowse still
needs the checksumming feature to reindex on changes.
I've contemplated various options for an external database program to
try and boost the speed of lookups, but other bugs are usually more
> * Then, using the current buffer's #include sentences, emacs should do
>the actual intelligent completion. By this I mean:
This is how it currently works. See
`semanticdb-find-test-translate-path' which is what I use to debug
problems in this feature. Also see `semanticdb-find-default-throttle'
for how to tune to your preference.
> - I start to write something and as soon as I hit the keybindings for
>semantic-ia-complete-symbol, emacs should complete as many characters as
>it possibly can given the various available possible completions to the
>written prefix, much like bash, like so:
> gtk_win[hit keybinding]
>since 'gtk_win' can only lead to (I'm not sure this is really true but
>it illustrates my point)
>it should add the characters 'dow_' and stop here since there are a lot
>of symbols in gtk that start with this prefix. Then on a second
>keybinding hit it should actually try to display the possible
>completions using the standard emacs' completions special window (I
>don't like dropdown menus like visual studio or eclipse but this could
>be configurable for those who do). This is all pretty much like bash
>would behave... only it's "intelligent" from the C point of view.
>The same would apply to a variable 'foo' of type 'struct Foo' with
>fields 'bar' and 'bat':
> foo.[hit keybinding]
>either accessed with '.' or '->' if 'foo' was a pointer. And so on and
>so forth for the various C constructions.
>I'm almost certain CEDET can't provide an experience like this yet and
>maybe I'm being too demanding (I'd love to control a computer with my
>mind ;-). Anyway I'd like a factual answer regarding what CEDET can do
>today and what are the plans for the future. Would any of this be
>feasible? Does it even make sense?
I recently (to CVS) added the command `semantic-complete-self-insert'
which you could bind to . or > in C/C++. The idea is it will go into
"completion mode" so SPC and TAB act as in a minibuffer, and
completions show up in a tooltip.
At the moment, this happens in `global-semantic-idle-completions-mode'
as a timer, but over time I've been finding that more annoying than
I don't know what the ideal interface/keybindings/whatever are, but
the basics are there waiting to be bound to a key.
The other aspect is the "smart" part, or figuring out where the
completions come from. What you describe is what the system was
designed to do, but it has some problems. The problems usually lie in
one of two places:
1) semantic can't find the header with the definition you want.
2) semantic's context analyzer gets confused.
As far as I know, it is just a matter of finding and debugging these
>I should note that I don't think I have the skills to implement this (my
>emacs lisp knowledge is very basic and I don't have experience with
>large projects) but I'd surely help as far as I could, learning in the
If you know how to bind keys, collect stack traces, and make small
examples that "don't work as expected", then please try out some of
the above and, as you suggested, update the web page to assist others
with what you learn!
Sadly, statements like "I haven't been able to get it to work" are
common, and don't help me solve problems.
>Thanks for listening,
> As a sidenote I have been thinking that maybe even better for
>performance and code reuse reasons emacs should use a helper process to
>to these things. More: these days with indexers like tracker
>[http://www.gnome.org/projects/tracker/] that helper process could spawn
>a dedicate tracker daemon just to handle all this indexing and database
>maintnance. Obviously indexing rules to generate correct semantic
>information for each language would have to be added to tracker.
Hmm, I'd been thinking about using a generic indexer (common for
search engines, help browsers, etc) to provide cscope like features
for any language in a generic way. One was installed where I work
recently for this purpose, and I'll pass judgment on it after I get to
use it for a while. I suspect it will have problems with namespaces,
classes, and fields and not be very useful.
Hope this was helpful.
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