"Eric M. Ludlam" <eric@...> writes:
>>>> Bruce Stephens <bruce+cedet@...> seems to think that:
>>Just some minor points. I find it surprising that
>>semantic-tag-type-static isn't called semantic-tag-type-static-p (or
> That seems like a good idea (though the function is
> semantic-tag-static). That is also true of -leaf and -abstract.
> It didn't occur to me that they were boolean insofar as the default
> action is to return a value out of the tag structure. That value
> could be anything.
OK, that makes sense.
>>It seems non-trivial to determine the type of something. That's not
>>so surprising, since types seem hard to encode sanely. I've been
>>using semantic-format-tag-type, which appears to be the right thing to
>>use, although it's not mentioned in the appdev manual yet.
> That is a function used by other format routines. For example, if you
> pass in a tag of class type, it formats it expecting to precede an
> actual definition, such as a function.
> It is more likely that it should be part of the language dev guide,
> but if you think it is useful in other areas, that's fine too.
I think many applications are going to be interested in types, so
they'll want something. It seems likely that producing a
language-dependent string will be acceptable, at least sometimes.
>>There seems to be no distinction between the C++: "class foo: public
>>bar" and "class foo: private bar". (That's unlikely to be critical
>>for anything; I just thought I'd mention it.)
> I'm not too sure. Klaus Berndl has been updating the C++ parser
> lately. That sort of information is certainly important for smart
> completion since it specifies which part of the parent class you
> have access too in any given method.
> The routine that does that in semantic-analyze isn't implemented yet
> though. :(
> The order of the :member entries in the originating tag must be in
> buffer order. This is important for the partial reparse mechanism
> which uses this order for restricting reparse actions to small
> subsets of a buffer.
> It would certainly be useful for tools using the tags to perform
> such an action. Such a routine would be useful in semantic-sort.el
> as a means of rearranging children in a tag with no side-effects.
All true, I think. I hadn't thought of keeping buffer ordering, but
that's obviously going to be needed, sometimes.
>>What does semantic-tag-variable-default return? (i.e., what's it
>>supposed to mean?)
> A declaration, such as:
> int a = 1;
> has a default value of 1.
OK, makes sense.
>>My project at the moment is to put useful information from
>>semantic-bovinate-toplevel into a PostgreSQL database. (i.e., this
>>isn't really the right way to do it (which would be to build an
>>alternative to the file backend), but it's nice and independent from
>>the rest of semantic, so it's easier for me.) It's slow
>>(unsurprisingly), but I think it's going to turn out to be fast enough
>>to be useful in the common case where most files don't change much.
> [ ... ]
> That sounds like a smart way to do it. Any new backend would be a
Actually, I think it's probably better if I use (semanticdb-get-tags
(semanticdb-file-table-object fn)), which seems like it ought to play
better with the normal file cache.
> While it may be slow for typical semanticdb usage, it would be ideal
> for system databases which are very large, and are only ever
> searched. (Usually by name or name-regexp.)
"Typical" as defined now. But I think that's just because it's too
slow to use it in any other way. Getting lots of information about
what's in the current buffer is cool, but it's often not that
useful---often I can remember what's in the current file, and I want
the computer to remind me about other files.
> Postgres would probably be faster than the -file method when
> searching through huge collections of C or C++ headers for symbols
> in the global namespace. Right now this action is so slow it is
> disabled in the code.
And it allows ad hoc queries, which should be fun. For example, when
using a C API, it's often useful to look at functions whose first
argument is a pointer to some data type. That's easy to do if
everything's in a database. In fact, with my current schema, that's
"select tags.name from tags,args where tags.class='function' and
tags.id=args.function and args.argno=0 and args.type='class
BN_ULONG*' and tags.file like '%.h';".
(I'm not trying to hide this code, although it's very rough at the
moment. If anyone's interested, and has Tom Lord's arch
<http://www.gnu.org/directory/arch.html>, you can get it like this:
http://www.cenderis.demon.co.uk/archives/bruce-2004; tle get