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!
- 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).
- 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.
- 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.
Interested to get people's thoughts on this.
Cheers, Matthew Brush