Sorry for being slow. I've been sick this week.
>>> joakim@... seems to think that:
>I've been spending some time on trying to implement ebrowse supot for
>cedet. If I'd gotten very far, I'd cal this mail a "progres report"
>rather than "notes" :)
>I have spent most of my time just trying to understand eieio, ebrowse,
>and the semanticdb.
>So far I've figured out this:
>- I think the code in the semanticdb-ebrowse skeleton doesnt realy
> work. Creating the ebrowse structure works, using ebrowse-read.
> The "splitting" that is called "stripping" in the code, seems to
> assume there is only 1 class per file. Also, there is code to
That sounds like a shortcut from when I was trying to solve the
> retrieve the ebrowse equivalent of a "table", but that is just a
In order for a database that is outside semantic to return search
results, it must fabricate proxy tables. In semanticdb-el you will
see it just makes a tmp version, and puts the results in it. The
purpose of the table is to override the default value of major-mode so
it is clear what language the table is for.
If the skeleton is 'broken', then you should refer to semanticdb-el,
as that one works.
>I've tried to implement something that works like this:
>- read the ebrowse structure
>- for each class tree, figure out the corresponding declaration file
>and put it on an assoc list for that file(this is nearly the same idea
>as the existing code)
>Currently this code doesnt work well, but it doesnt seem so hard
>Then there are problems when searching the ebrose structures. The
>existing ebrowse api seems geared towards just jumping to the
>declarator of a tag, not returning info about it. Currently I think
>one has to recurse the tree linearly to find a tag, which feels
Folks tell me it's fast, but perhaps they only refer to the generation
of the tags database. I suspect the mechanism semanticdb uses to
optimize its search will help with the ebrowse problem also.
>Then there are some problems converting the match to a semantic tag,
>because the ebrowse tag only seems to contain a single point, not the
>start and end of a declaration. It almost seems beter to just convert
>the ebrowse trees to something more like semantics internal structures
>directly when reading.
An omniscient database does not need to return everything there is to
know about a tag. Getting the name, data type (return type), argument
list and those data types, and fields to classes/structures are about
all it really needs for the completion engine to function. If some of
that is missing, that might be ok for a subset of semantic functions.
If the ebrowse database is to be used to lookup or jump, then just the
single location value is likely ok. Getting a full tag would require:
1) Look up the tag, get single location.
2) Go there
3) parse the file with semantic.
4) get the tag at that location.
Too bad that brings the slow semantic parser back in. :(
Thanks for looking into this. The semanticdb-el greatly improved
semantic's ability to be helpful in Emacs lisp (except that the
existing Emacs Lisp tools are better than the semantic ones.) I
Expect the same to be true from ebrowse.
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