Hi,
I started working on support for reading Exuberant Ctags files. The commit message sums up most of the details I hope. If anyone wants to try it out and/or review the code, that would be much appreciated.
The relevant commit is here on my 'ctags-support' branch: https://github.com/codebrainz/geany/commit/a642077c47ea444e9b13b9d2ad244be08...
Or the attached patch has the same information.
I haven't tested a whole lot but it seems to be working well, allowing colourizing of the tags and auto-completion. It doesn't (yet) get the arguments list for functions (haven't found a clean way yet), so the calltips for function tags are pretty useless.
There is still much to be done, but it's a good start.
Cheers, Matthew Brush
On Wed, May 25, 2011 at 06:29, Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
I started working on support for reading Exuberant Ctags files. The commit message sums up most of the details I hope. If anyone wants to try it out and/or review the code, that would be much appreciated.
The relevant commit is here on my 'ctags-support' branch: https://github.com/codebrainz/geany/commit/a642077c47ea444e9b13b9d2ad244be08...
Or the attached patch has the same information.
I haven't tested a whole lot but it seems to be working well, allowing colourizing of the tags and auto-completion. It doesn't (yet) get the arguments list for functions (haven't found a clean way yet), so the calltips for function tags are pretty useless.
Hi Matthew,
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:
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)
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.
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.
Cheers,
Jiri
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
On Wed, May 25, 2011 at 17:29, Matthew Brush mbrush@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!
- 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.
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
On 05/25/11 09:03, Jiří Techet wrote:
On Wed, May 25, 2011 at 17:29, Matthew Brushmbrush@codebrainz.ca wrote:
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.
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.)
I think that would be best. Tag manager isn't really a binary format, but there's no reason to use a format that you can't punch in on a normal keyboard. Seeing that the Ctags format is somewhat of a "standard", supports all of the needed information, and is used by many other editors, it seems only logical to use this format.
Another bonus is that Ctags format has the filename in it, which could potentially be useful for the "Go to Tag Definition" feature, maybe?
My 2¢
Cheers, Matthew Brush
On Wed, May 25, 2011 at 22:16, Matthew Brush mbrush@codebrainz.ca wrote:
On 05/25/11 09:03, Jiří Techet wrote:
On Wed, May 25, 2011 at 17:29, Matthew Brushmbrush@codebrainz.ca wrote:
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.
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.)
I think that would be best. Tag manager isn't really a binary format, but there's no reason to use a format that you can't punch in on a normal keyboard.
The tags are saved in tm_tag_write() using code like
fprintf(fp, "%c%d", TA_TYPE, tag->type);
so the file contains binary representation of integers and other types so it is a binary format.
Seeing that the Ctags format is somewhat of a "standard", supports all of the needed information, and is used by many other editors, it seems only logical to use this format.
Completely agree.
Another bonus is that Ctags format has the filename in it, which could potentially be useful for the "Go to Tag Definition" feature, maybe?
Good point.
Jiri
On 05/29/11 17:33, Jiří Techet wrote:
On Wed, May 25, 2011 at 22:16, Matthew Brushmbrush@codebrainz.ca wrote:
I think that would be best. Tag manager isn't really a binary format, but there's no reason to use a format that you can't punch in on a normal keyboard.
The tags are saved in tm_tag_write() using code like
fprintf(fp, "%c%d", TA_TYPE, tag->type);
so the file contains binary representation of integers and other types so it is a binary format.
It contains ASCII textual representations of integers doesn't it?
Either way, it's not a very user friendly format :)
Cheers, Matthew Brush
On 30 May 2011 10:43, Matthew Brush mbrush@codebrainz.ca wrote:
On 05/29/11 17:33, Jiří Techet wrote:
On Wed, May 25, 2011 at 22:16, Matthew Brushmbrush@codebrainz.ca wrote:
I think that would be best. Tag manager isn't really a binary format, but there's no reason to use a format that you can't punch in on a normal keyboard.
The tags are saved in tm_tag_write() using code like
fprintf(fp, "%c%d", TA_TYPE, tag->type);
so the file contains binary representation of integers and other types so it is a binary format.
It contains ASCII textual representations of integers doesn't it?
Not really, TA_TYPE is 204 and %c writes the character whose value is 204, assuming the system supports 8 bit characters I guess.
Either way, it's not a very user friendly format :)
+1
Cheers Lex
On 05/29/11 18:31, Lex Trotman wrote:
On 30 May 2011 10:43, Matthew Brushmbrush@codebrainz.ca wrote:
On 05/29/11 17:33, Jiří Techet wrote:
On Wed, May 25, 2011 at 22:16, Matthew Brushmbrush@codebrainz.ca wrote:
I think that would be best. Tag manager isn't really a binary format, but there's no reason to use a format that you can't punch in on a normal keyboard.
The tags are saved in tm_tag_write() using code like
fprintf(fp, "%c%d", TA_TYPE, tag->type);
so the file contains binary representation of integers and other types so it is a binary format.
It contains ASCII textual representations of integers doesn't it?
Not really, TA_TYPE is 204 and %c writes the character whose value is 204, assuming the system supports 8 bit characters I guess.
Yeah, maybe not in ASCII, but I wouldn't consider it "binary" anymore than any other zero-terminated text file containing chars > 127. For example, Geany can open these files (as ISO-8859-1) and edit them. Also it's not opened with "rb" mode, which I thought made a difference on Windows?
Anyway, it's mostly semantics, everything is binary really. The format is still non-standard and user-unfriendly.
Cheers, Matthew Brush
Hi Jiri,
Support all you say, especially well done and thanks to Matthew.
Except:
- 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.
Using an external tool won't work with real-time tag parsing
Cheers Lex
On 05/25/11 14:15, Lex Trotman wrote:
Except:
- 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.
Using an external tool won't work with real-time tag parsing
IIUC this is a separate concern. The global tags will come from Ctags format files loaded on startup and the workspace tags will still be parsed on-the-fly from the open documents.
Personally I think Geany still generating tag files, equivalent to using the 'ctags' program with the correct options, is a really good idea.
Cheers, Matthew Brush
On 05/25/11 06:37, Jiří Techet wrote:
- 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)
Done (see ctag_format.c): https://github.com/codebrainz/geany/commit/df2164eaa4d881bfcc2efde7de1105c39...
Hopefully I haven't done this stupidly, suggestions for improvements are most welcome.
Cheers, Matthew Brush
On Thu, May 26, 2011 at 05:49, Matthew Brush mbrush@codebrainz.ca wrote:
On 05/25/11 06:37, Jiří Techet wrote:
- 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)
Done (see ctag_format.c): https://github.com/codebrainz/geany/commit/df2164eaa4d881bfcc2efde7de1105c39...
Hopefully I haven't done this stupidly, suggestions for improvements are most welcome.
Looks good, I haven't had time to test it yet...
Jiri