[Geany-devel] Exuberant Ctags Support

[Jiří Techet]

On Wed, May 25, 2011 at 17:29, Matthew Brush <mbrush at codebrainz.ca> wrote:
> On 05/25/11 06:37, Jiří Techet wrote:
>
>>
>> as this is something I wanted to do myself, I really like it! I've
>> been looking at the code only so far; I'll test it once I have access
>> to my computer in the evening. A few comments:
>
> Great, thanks!
>
>>
>> 1. In tm_tag.c it would be better to have ctagKinds languageKinds[]
>> separate for each language and then have allKinds array indexed by
>> lang_id containing languageKinds[] of all languages. So to get to
>> language's tags, you would just do allKinds[lang_id] instead of going
>> through the whole list every time. (a dummy entry would be used for
>> lang_id's not present in the table)
>
> Good idea, then it only has to go through ~10 entries max before it finds
> the finds the langType (or doesn't).
>
>>
>> 2. You can get function parameters from extension fields when you run
>> ctags with --fields=+S (and I believe you get variable type with "t").
>> Check the man pages of ctags. I think this is safer than using your
>> USE_HACKS code.
>
> Yeah, that's certainly the way, but I wanted to support "any" CTags files
> that could be generated, particularly with the default (no) options/old
> format.  But see below.
>
>>
>> 3. More general comment - if we have ctags file parsing support, it's
>> a question whether Geany should continue using the old format and its
>> generation. Tags generation would be then redundant in Geany if you
>> can do the same with ctags (and ctags is the right tool to generate
>> tags, not a text editor). Geany's documentation would then just say
>> what flags should be used for ctags in order to create all the
>> necessary fields.
>
> I wasn't thinking of it like this, but it does make sense.  The only
> problems I see are that it requires the user to have another specialized
> program to generate tags and that some languages supported by Geany are not
> supported by the CTags (at least on my system), particularly Vala comes to
> mind.  Maybe Vala support could be pushed back upstream.
>
> Also, as above, if the user was told which flags to use for Ctags, then it
> would make the parsing code more robust.  What's more, if we used the Ctags
> format as the main format, then we could drop the pipe separated format as
> well since Ctags format is (nearly) as easy to generate by hand as the
> pipe-separated format and also Ctags program supports the languages that
> necessitated supporting that pipe-format in the first place I think (as the
> code comment says "alternative parser for Pascal and LaTeX global tags
> files...").
>
> I personally think it's nice for Geany to be able to generate tag files
> itself though, especially since it would still have all the parsing code for
> parsing the open source files.  Dumping the list of tags parsed to a
> plain-text (Ctags format) file seems fairly trivial.  This would remove the
> need for the user to *have* to have Ctags on her system.

Good points - it's a bit unfortunate that ctags hasn't been maintained
very actively in the past few years and that Geany has to maintain its
own fork of it instead of pushing the changes upstream. It wouldn't be
easy to extract the Vala ctags generation from c.c because there are
really many changes if you compare it with the ctags version.

OK, one more idea - how about generating the Geany's tag file in the
ctags format? (I don't like the current tags binary format much.)

Cheers,
Jiri