[Geany-Devel] Proposal: move tag type ctags->geany mapping out of individual parsers

[Colomban Wendling]

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?