"Eric M. Ludlam" <eric@...> writes:
>>>> joakim@... seems to think that:
>>I've worked some more on the semanticdb ebrowse backend.
>>Currently I can do this:
>>(setq D (semanticdb-create-database
>> semanticdb-project-database-ebrowse "/home/joakim/rosegarden/gui/"))
>>D is then a database instance. (In Erics example D was a path, but I
>>didnt quite get why, since the databse ought to get garbed, and I
>>didnt understand how to acess the actual database in other tests if I
>>didnt have a reference to it)
> Emacs/Semanticdb can have a lot of databases active at any moment.
> The databases can be of different types, such as file based (the one
> used for files parsed w/ semantic) or omniscient (that knows lots of
> stuff, but not necessarily while files they come from).
> When doing a search, searching all DBs in order would be unwise.
> Therefore, the first thing that happens is a path is generated. In
> this case, PATH means a list of places where you might find
> If you have a single database, and pass it to a search routine, then
> that database (and the DBs it references) is the path. If you have a
> list of tags returned as a result from a previous search, that tag
> list is the path... though a bit weird I guess.
> If you pass in nil, then an algorithm calculates a path for you
> which is just a list of databases. The code in semanticdb-el puts a
> single omniscient database on the default path for all searches in
> Emacs Lisp.
> See the doc for semanticdb-find-translate-path for more on what you
> can pass in.
> Does that help?
Yes, but its still a little unclear where the database is actually
This call doesnt normally have the side-effect of storing the
generated db anywhere, right?
(setq D (semanticdb-create-database
Where would I'd hook in semanticdb-project-database-ebrowse so this
>>(RoseGarden is a fairly large free c++ midi sequencer I use for tests.)
>>Then I can do:
>>(semanticdb-find-tags-by-name-method (semanticdb-file-table D "rgled.cpp") "KLed")
>>([ebrowse-ms "KLed" nil 0 nil nil 0 0 nil "e shape, QWidget *parent, const char *name )\n :" 5687]
>> [ebrowse-ms "KLed" nil 0 nil nil 0 0 nil "lor& col, QWidget *parent, const char *name)\n :" 5363]
>> [ebrowse-ms "KLed" nil 0 nil nil 0 0 nil "Led::KLed(QWidget *parent, const char *name)\n :" 5062])
>>which are the 3 ebrowse member structures for the constructor KLed in
>>file rgled.cpp. (this currently only works for functions)
>>The question now, then, is what the corresponding semantic tags would
>>look like, and what more I need to be able to test everything in context.
> For each entry, I think you would do this:
> (let ((txt (aref T 9))
> (type (do-something-to-txt-1 txt))
> (args (do-something-to-txt-2 txt))
> (... ))
> (semantic-tag-new-function (aref T 1)
> :constructor ...
> :destructor ...
> :something-else ...
I think txt is meant to just be used to locate the definition, and as
you can see they appear to be a bit truncated. I thus believe txt cant
be used to extract anything useful, normally.
> where the text is parsed for the data you want.
> For example, if you know where the arg-list is, you might use
> (split-string txt "," t)
> and then for each one try and parse the data type. It may be you
> could use the existing semantic C parser to parse the argument list.
> To do that, you may need to add new %scopestart tokens in c.by.
> Getting the return type is likely the most important thing to do, but
> I don't see that data in the info you have.
> For a first pass, you could really just have:
> (semantic-tag-new-function (aref T 1)
> and then get to do stuff with it right away.
But how could this be used usefully?
One can also get the defining file from ebrowse,
which I figure I would add like
(semantic-tag-new-function name return_type :filename where_tag_is_defined )
> If ebrowse has an interface to the vector (which I called T above),
> then clearly that would be the preferred way to access it.
ebrowse does indeed define acessors for the structures.
> If you want to use your new interface for files a user is editing,
> then you would need to extract the positional information, and append
> it to the created tag. Then call `semantic--tag-expand' to force the
> tag to be cooked into something you can use, but that is outside the
> scope of a semanticdb project. semantic-texi.el or semantic-html.el
> would be ok examples.
This part is confusing. Why do I need to call tag-expand?
Cant I just create the start-end proxy and pretend its cooked already?
And, what would the point be of returning tags withouth position information?
> Does this help?
Indeed your help is always greatly apreciated.
> 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