On Wed, 17 Sep 2008 12:54:30 +0100, Nick Treleaven <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Sep 2008 23:08:52 +0200 > Enrico Tröger <[EMAIL PROTECTED]> 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. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc
pgpOSap7dLw4I.pgp
Description: PGP signature
_______________________________________________ Geany mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
