>>> joakim@... seems to think that:
>"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?
A "database" in semanticdb is merely an interface, or a virtual class
with some basic infrastructure hanging from it. As such, the
"storage" is whatever is implemented by someone who writes a new
The default database is written to store tags in memory in long lists,
and write that list to disk when Emacs exits.
The "system" database is the same, except designed to be written when
you create it, and read into memory on startup.
The emacs-lisp database has no storage. It calls Emacs commands to
query the symbol lists, and knows how to convert that data into tags.
Nothing is ever saved from that database.
The ebrowse database, when I last worked on it, had no storage of it's
own. It calls ebrowse commands which do mysterious (to me) things.
Thus, no, it will store nothing on disk, and storage (as accessed by
the search commands) is whatever you write.
>(setq D (semanticdb-create-database
> semanticdb-project-database-ebrowse "/home/joakim/rosegarden/gui/"))
>Where would I'd hook in semanticdb-project-database-ebrowse so this
This is how semanticdb-el does it:
;; Create the database, and add it to searchable databases for Emacs Lisp mode.
(defvar-mode-local emacs-lisp-mode semanticdb-project-system-databases
"Search Emacs core for symbols.")
for a single omniscient database.
If you want to reference your database by a path, meaning some C code
and semantic-default-c-path include a directory to where somefile.h
is, THEN in that case.... uh. hmmm.
Ah, your newly created database must have the 'reference-directory
slot set. Once that is set, then the `eieio-instance-tracker' parent
class (to all databases) will find it automatically when asked for
from a particular directory.
That bit probably will require some research and experimentation.
See semanticdb-create-database in semanticdb.el line 152 for the
specific implementation of how databases are found by a particular
location on disk.
That would be
(semanticdb-find-tags-by-name "KLed" nil)
>>>(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.
Well, thats a drag. In order to get all the useful tag information,
then you would need to do this:
(set-buffer (find-file-noselect (the file0)))
(goto-char (location-from ebrowse))
which would not actually save any time.
Alternately we could tweak the existing semantic parser to allow it to
parse a single tag at point. I think that'd be ok as is except we
don't know when the tag is a child of some namespace or class.
I'm surprised ebrowse has so little information in it's system. I
seem to recall the browser have a bit more to it.
>> 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?
Well, it'd let you test the infrastructure that ties databases
together, but you're right. All the useful tools depend on a datatype
or a position.
>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 )
That would indeed be useful thing to add.
Adding the :filename attribute is always useful if the created tags
don't have overlays.
>> 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?
If you try to use ebrowse as a file parser, then that's just part of
the infrastructure to fabricating tags at parse time.
If you are returning things out of a fancy database and want to
include positional information, then you are breaking new ground, and
what you suggest may be fine.
>And, what would the point be of returning tags withouth position information?
Tags like that can be used in the smart completion system, or in the
summary tool. The analyzer doesn't really care where tags come from,
only what the data is so it can fabricate useful summaries or
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