On Wed, 17 Sep 2008 12:54:30 +0100, Nick Treleaven firstname.lastname@example.org wrote:
On Fri, 5 Sep 2008 23:08:52 +0200 Enrico Tröger email@example.com wrote:
a) we add the CSS filetype to the list of filetypes which use this format (pipe-separated).
I'd prefer a) as your list is 'generated' manually and not by a script and so the pipe-separated format is easier to maintain but it's not possible without changing the source code.
I'm still not 100% what is the best way. But we shouldn't look back to much to Geany 0.14. Even though 0.15 will might take some more time, the solution should be something that is working for all tag file in the same way. Providing data pipe seperated and in tagmanager style mixed up will be ugly to maintain I guess.
Hmm, 'ugly to maintain'? Maintaining a binary file is less ugly than a pipe-separated tag file? The problem with the tagmanager format is that it mostly can't be edited. And so, for the Pascal or LaTeX tag files you need to get them parsed but probably they can't be parsed with the current code. This is why there is another, easier format.
I don't think having all tags file in the tagmanager format would make them easier to maintain. Of course, this is true for real generated file like the globals tags file for C/C++. But probably not for other formats. Same for the PHP tags file which is parsed from a text file from the PHP project. To get it generated by the tagmanager code you would need to generate a PHP file with all these information so that it could be parsed by the PHP parser and then written to a tags file. But IIRC then function signatures (return values, argument lists) are lost and we just loose information compared to the current way.
There are good reasons to have both, CTags is unlikely to be able to support full tag parsing for all languages Geany wants to support.
I think a nice solution would be to support both formats for each filetype. Maybe with different extensions for pipe-separated tags files. That way everyone is happy, and users could even write pipe-separated tags files as a kind of custom calltips/autocompletion feature, whilst still loading TM-generated tags files.
Yeah, that's a great idea and solves the problem, at least for future versions.