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

[Colomban Wendling]

Hey,

Le 07/11/2014 17:38, Jiří Techet a écrit :
> […]
> 
> I noticed that it's necessary to change the tag types (the GoKinds[]
> array in the case of go) to match the supported types in the tag
> manager and Geany. This has to be done for every parser because the
> tag types aren't standardized in any way in ctags and can be more or
> less arbitrary.
> 
> In my opinion, doing this in the parser itself is a bit unfortunate -
> when updating a parser from the ctags repository, these have to be
> changed. Worse, if ever something like ctags shared library happens
> and all the parser support is moved there, these will have to be
> always changed in every parser after updating to new ctags version.
> 
> I think it would be better to keep the tag types inside the individual
> parsers as they are and have a separate table in the tag manager which
> will map the ctags type to the type used by Geany.

Yep, I was thinking the same a few days ago while discussing a little
CTags shared library, and had the same idea :)

When upstream CTags was basically dead it didn't matter much as we
pretty much never updated anything, but now there is some activity again
(even though it's not upstream yet) it would probably make sense.

Note that there is another potential issue when importing a parser: use
of MIO.  It affects fewer parsers, but a few are using fpos_t (mostly
through getInputFilePosition()), and we can't use this for memory
parsing.  It's generally just a matter of s/fpos_t/MIOPos/ and the
compiler will whine, but that's a step.

> The only disadvantage of this approach I can think of is that the type
> names might change in ctags and we could easily miss this change and
> not update the mapping. For this reason it would be good to add some
> "integrity check" function which goes through all the kinds in ctags
> for every language and checks whether they are mapped to Geany's tag
> types and vice versa. But I think this can be done quite easily so it
> isn't a real problem.

Yeah, updating would still require some care, but not much more than
right now.  And as you say we could have a tool listing missing mappings.

> What do you think?

I didn't really think of the implications so I can't tell if it has
other problems, but I feel like it's a good way to go.

Regards,
Colomban