Le 08/11/2014 12:27, Jiří Techet a écrit :
[…]
Good, if there's an agreement here, I can have a look at it. But I'll wait until some of my TM patches get merged. There are a bit too many of them floating around and I'm slightly getting lost in all of my branches.
I'll try to merge the tm branch as soon as possible, just a few small comments as you saw.
Another thing I have noticed is that it would be good to make sTagEntryInfo as close to ctags as possible - for instance, the "signature" member in Geany is called "argList" in ctags and "seekPosition" is unused and not present in ctags.
Good idea indeed. I just gave it a look, and it should be pretty easy but for our "varType" field (a string) v.s. CTags' "typeRef" (a pair of strings of the form [kind, name]). Those are not really the same, and are both somewhat interesting (though ours seems a little better to me):
Our varType is used to report a function's return type, or a variable type, or the type mapped to a typedef for example. And it includes the whole type, including 'struct', '*'s and '[]' -- which is both useful (for the user to see) and partly impractical (for using it from the code).
CTags' typeRef seems only used to report C typedefs, and has two parts, a "kind" part and a name part. For example, `typedef struct foo bar;` would generate a typeRef of ["struct", "foo"] -- which is partly useful to resolve the correct definition of "foo" in case there are several, but not so much as generally you can rule out anything but types when resolving a typedef.
The problem here is that there isn't always a "kind" to associate with the return type of a function, there only is if it's a custom type, and even then only it if isn't a typedef. E.g. we have nothing to put in typeRef's "kind" for `int printf(const char *fmt, ...)`, or even `GeanyDocument *document_get_current(void)`.
For now it's probably not so much of a problem as in CTags only the C parser seems to use it -- and we won't want to just use this one right away because it misses some things ours handle (yet the contrary is probably also true) -- but it might be useful to solve this problem anyway.
So, what do you think about this?