Hi Guys
I use Geany (version 0.14) quite extensively on Ubuntu (Hardy).
I have tried to create a tags file manually from the W3 spec (http://www.w3.org/TR/CSS21/propidx.html). Then I copied the file to "/home/gelie/.geany/tags", but somehow it does not work. Is there something else that I need to modify or am I missing something ?
Thank you in advance.
Gavin Elie (gelie) ICT - Web Administrator Parliament of South Africa http://www.parliament.gov.za
------ Please note: This email and its content are subject to the disclaimer as displayed at the following link http://webmail.parliament.gov.za/disclaimer.html
Hi,
On Thu, 21 Aug 2008 10:56:21 +0200 "Gavin Elie" gelie@parliament.gov.za wrote:
I have tried to create a tags file manually from the W3 spec (http://www.w3.org/TR/CSS21/propidx.html). Then I copied the file to "/home/gelie/.geany/tags", but somehow it does not work. Is there something else that I need to modify or am I missing something ?
I think we should integrate this into Geany distribution. Any opinions?
Frank
On Thu, 21 Aug 2008 10:56:21 +0200, "Gavin Elie" gelie@parliament.gov.za wrote:
Hey Gavin,
sorry for the delay.
I use Geany (version 0.14) quite extensively on Ubuntu (Hardy).
Cool!
I have tried to create a tags file manually from the W3 spec (http://www.w3.org/TR/CSS21/propidx.html). Then I copied the file to "/home/gelie/.geany/tags", but somehow it does not work. Is there something else that I need to modify or am I missing something ?
There are two problems:
Problem 1: The file has the wrong name: user-supplied tag files in ~/.geany/tags must be named 'bla.filetype.tags'. - 'blah' can be replaced by something more descriptive :) - 'filetype' must be a supported filetype ('css' is fine) - 'tags' is a constant
So, your file should be '~/.geany/tags/gavins.css.tags'. The prefix is important and must be present. This is also mentioned in the docs.
You can verify that this file is actually loaded when starting Geany from a terminal with the '-d' argument, like geany -d
Then open a CSS file and check the terminal output, there should be a line like: ** INFO: Loaded /home/user/.geany/tags/gavins.css.tags (CSS).
Problem 2: Geany doesn't support this format for CSS (yet). There are two possible solutions: a) we add the CSS filetype to the list of filetypes which use this format (pipe-separated). But this would only affect the SVN version, you still wouldn't be able to use your file with Geany 0.14 b) you or someone else write a script which converts your file into the native tagmanager format.
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. The tagmanager format doesn't cause any changes to the code but isn't really nice for manual editing.
To get an idea how the tagmanager format looks like, see the files scripts/create_py_tags.py and scripts/create_php_tags.php in the SVN repository. Basically, it is a concatenation of the tagname, followed by an integer to identify the type of the next string, then this string, then the next identifying integer, and so on.
After all, if we have decided how to proceed, I agree with Frank to include this list in Geany if you, Gavin, agree.
Regards, Enrico
On Sun, 24 Aug 2008 20:49:44 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
There are two problems:
Another, smaller problem: to get it working properly, '-' (dash) should be in the list of wordchars otherwise something like 'text-align' will be treated as two words and so auto completion won't work. I think changing the 'wordchars' setting in the filetypes.css filetype definition file should work, but I didn't test it yet.
Regards, Enrico
On Sun, 24 Aug 2008 20:49:44 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
Hey,
as some time passed by, let's start again.
Geany doesn't support this format for CSS (yet). There are two possible solutions: a) we add the CSS filetype to the list of filetypes which use this format (pipe-separated). But this would only affect the SVN version, you still wouldn't be able to use your file with Geany 0.14 b) you or someone else write a script which converts your file into the native tagmanager format.
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'd still prefer a) and like to get it working if there are no objections.
After all, if we have decided how to proceed, I agree with Frank to include this list in Geany if you, Gavin, agree.
In the meantime I would disagree to this and instead provide the file on www.geany.org/Download/Extras for download. (if anyone is bored, write a plugin which downloads such files automatically :D)
This way we could also move most of the keywords which are defined in filetypes.css into the tags file and add missing ones (see https://sourceforge.net/tracker/?func=detail&atid=787794&aid=2082597...).
What do you think? Jason?
Regards, Enrico
As the reporter of the bug mentioned, no complaints from me! Although, and this is only slightly related, I haven't noticed any way to identify pseudo-classes and pseudo-elements as separate entities. An example from some CSS I have been using recently:
.sort_asc:hover::after { content: ' \25BE'; /* Black Down-Arrow */ }
Ideally, the :hover pseudo-class and ::after pseudo-element should be lexed and styled differently by Scintilla. If this is a Scintilla issue, (needs double-checking) I would be glad to pick this up and work on it.
But any work on Scintilla without Geany able to pass it the necessary CSS keywords would be kind of silly. :P
Jay
Enrico Tröger wrote:
On Sun, 24 Aug 2008 20:49:44 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
Hey,
as some time passed by, let's start again.
Geany doesn't support this format for CSS (yet). There are two possible solutions: a) we add the CSS filetype to the list of filetypes which use this format (pipe-separated). But this would only affect the SVN version, you still wouldn't be able to use your file with Geany 0.14 b) you or someone else write a script which converts your file into the native tagmanager format.
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'd still prefer a) and like to get it working if there are no objections.
After all, if we have decided how to proceed, I agree with Frank to include this list in Geany if you, Gavin, agree.
In the meantime I would disagree to this and instead provide the file on www.geany.org/Download/Extras for download. (if anyone is bored, write a plugin which downloads such files automatically :D)
This way we could also move most of the keywords which are defined in filetypes.css into the tags file and add missing ones (see https://sourceforge.net/tracker/?func=detail&atid=787794&aid=2082597...).
What do you think? Jason?
Regards, Enrico
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, 04 Sep 2008 11:40:36 -0700, Jason Oster parasytic@gmail.com wrote:
As the reporter of the bug mentioned, no complaints from me! Although, and this is only slightly related, I haven't noticed any way to identify pseudo-classes and pseudo-elements as separate entities. An example from some CSS I have been using recently:
.sort_asc:hover::after { content: ' \25BE'; /* Black Down-Arrow */ }
Ideally, the :hover pseudo-class and ::after pseudo-element should be lexed and styled differently by Scintilla. If this is a Scintilla issue, (needs double-checking) I would be glad to pick this up and work on it.
After having a short look at it, I'd say the CSS lexer of Scintilla doesn't support pseudo-elements. It seems the "after" is styled the same as the pseudo-class before. But I don't know CSS at all not sure about all this.
Regards, Enrico
Yep, that's the problem. ;) They should be styled differently, since they are not entirely equivalent. The use of two colons on the pseudo-elements (and the fact that they need to appear AFTER any pseudo-classes, if they exist) are not handled by Scintilla, so far as I know. Although, the two colons thing wasn't even suggested until CSS3.
But like I said, I wouldn't mind working on the Scintilla side of this one if you guys want to handle Geany's keywords. It just needs pseudo-classes and pseudo-elements separated, and whatever list of missing keywords added for the styling. If you can do all of that in the tag manager, great! I'm not familiar with it.
Jay
Enrico Tröger wrote:
On Thu, 04 Sep 2008 11:40:36 -0700, Jason Oster parasytic@gmail.com wrote:
As the reporter of the bug mentioned, no complaints from me! Although, and this is only slightly related, I haven't noticed any way to identify pseudo-classes and pseudo-elements as separate entities. An example from some CSS I have been using recently:
.sort_asc:hover::after { content: ' \25BE'; /* Black Down-Arrow */ }
Ideally, the :hover pseudo-class and ::after pseudo-element should be lexed and styled differently by Scintilla. If this is a Scintilla issue, (needs double-checking) I would be glad to pick this up and work on it.
After having a short look at it, I'd say the CSS lexer of Scintilla doesn't support pseudo-elements. It seems the "after" is styled the same as the pseudo-class before. But I don't know CSS at all not sure about all this.
Regards, Enrico
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, 05 Sep 2008 14:22:50 -0700, Jason Oster parasytic@gmail.com wrote:
Yep, that's the problem. ;) They should be styled differently, since they are not entirely equivalent. The use of two colons on the pseudo-elements (and the fact that they need to appear AFTER any pseudo-classes, if they exist) are not handled by Scintilla, so far as I know. Although, the two colons thing wasn't even suggested until CSS3.
But like I said, I wouldn't mind working on the Scintilla side of this one if you guys want to handle Geany's keywords. It just needs pseudo-classes and pseudo-elements separated, and whatever list of
This is kind of independent. At the very first stage, Scintilla, i.e. LexCSS needs to separate between pseudo-elements and pseudo-attributes. Then we can define lists of those in Geany.
Regards, Enrico
Yep, that's the problem. ;) They should be styled differently, since they are not entirely equivalent. The use of two colons on the pseudo-elements (and the fact that they need to appear AFTER any pseudo-classes, if they exist) are not handled by Scintilla, so far as I know. Although, the two colons thing wasn't even suggested until CSS3.
But like I said, I wouldn't mind working on the Scintilla side of this one if you guys want to handle Geany's keywords. It just needs pseudo-classes and pseudo-elements separated, and whatever list of missing keywords added for the styling. If you can do all of that in the tag manager, great! I'm not familiar with it.
Jay
Enrico Tröger wrote:
On Thu, 04 Sep 2008 11:40:36 -0700, Jason Oster parasytic@gmail.com wrote:
As the reporter of the bug mentioned, no complaints from me! Although, and this is only slightly related, I haven't noticed any way to identify pseudo-classes and pseudo-elements as separate entities. An example from some CSS I have been using recently:
.sort_asc:hover::after { content: ' \25BE'; /* Black Down-Arrow */ }
Ideally, the :hover pseudo-class and ::after pseudo-element should be lexed and styled differently by Scintilla. If this is a Scintilla issue, (needs double-checking) I would be glad to pick this up and work on it.
After having a short look at it, I'd say the CSS lexer of Scintilla doesn't support pseudo-elements. It seems the "after" is styled the same as the pseudo-class before. But I don't know CSS at all not sure about all this.
Regards, Enrico
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Hi,
On Thu, 4 Sep 2008 20:08:59 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Geany doesn't support this format for CSS (yet). There are two possible solutions: a) we add the CSS filetype to the list of filetypes which use this format (pipe-separated). But this would only affect the SVN version, you still wouldn't be able to use your file with Geany 0.14 b) you or someone else write a script which converts your file into the native tagmanager format.
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'd still prefer a) and like to get it working if there are no objections.
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.
After all, if we have decided how to proceed, I agree with Frank to include this list in Geany if you, Gavin, agree.
In the meantime I would disagree to this and instead provide the file on www.geany.org/Download/Extras for download.
In addition to this, we might could store them inside the genay-plugin subversion repository and doing maybe a daily svn export to the webserver.
Regards, Frank
On Fri, 5 Sep 2008 01:16:55 +0200, Frank Lanitz frank@frank.uvena.de wrote:
Hi,
On Thu, 4 Sep 2008 20:08:59 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Geany doesn't support this format for CSS (yet). There are two possible solutions: a) we add the CSS filetype to the list of filetypes which use this format (pipe-separated). But this would only affect the SVN version, you still wouldn't be able to use your file with Geany 0.14 b) you or someone else write a script which converts your file into the native tagmanager format.
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'd still prefer a) and like to get it working if there are no objections.
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.
After all, if we have decided how to proceed, I agree with Frank to include this list in Geany if you, Gavin, agree.
In the meantime I would disagree to this and instead provide the file on www.geany.org/Download/Extras for download.
In addition to this, we might could store them inside the genay-plugin subversion repository and doing maybe a daily svn export to the webserver.
No, we don't want this, as we already discussed some time before. Having links to user-provided tag files in the Wiki on the Download/Extras page is fine and if someone needs webspace for hosting such files, just contact me.
Regards, Enrico
On Fri, 5 Sep 2008 23:08:52 +0200 Enrico Tröger enrico.troeger@uvena.de 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.
Regards, Nick
On Wed, 17 Sep 2008 12:54:30 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 5 Sep 2008 23:08:52 +0200 Enrico Tröger enrico.troeger@uvena.de 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