I'm trying to create a new Geany colour scheme, with only partial success.
I'm calling it Slick; I've created a slick.conf file, copied from the default.conf, and made some changes. Some of them work, and some are ignored. In particular, I want to change the colour of function names, so have this:
[named_styles] ... function=#0F0;#00F;true;true ...
(I set those colours so that it will be very obvious when it works!)
After copying the file to the relevant place and changing the scheme to Slick, function names remain obstinately black.
The documentation doesn't say (anywhere I can see) in which order the multiple .conf files are processed, or which overrides what.
Grateful for your suggestions.
On Sun, 22 Mar 2020 at 11:31, Austin Green austin.green@orcon.net.nz wrote:
I'm trying to create a new Geany colour scheme, with only partial success.
I'm calling it Slick; I've created a slick.conf file, copied from the default.conf,
Neither grep nor I can find a file called default.conf??????
and made some changes. Some of them work, and some are ignored. In particular, I want to change the colour of function names, so have this:
[named_styles] ... function=#0F0;#00F;true;true ...
(I set those colours so that it will be very obvious when it works!)
After copying the file to the relevant place and changing the scheme to Slick, function names remain obstinately black.
Does the lexer for whatever filetype the file is (you didn't say what type AFAICT) distinguish function names as a separate style (for eg C and C++ do not)?
The documentation doesn't say (anywhere I can see) in which order the multiple .conf files are processed, or which overrides what.
Nothing in the default .confs overrides anything else.
Cheers Lex
Grateful for your suggestions. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Thanks for responding, Lex.
On Sun, 22 Mar 2020 12:47:56 +1000 Lex Trotman elextr@gmail.com wrote:
I'm calling it Slick; I've created a slick.conf file, copied from the default.conf,
Neither grep nor I can find a file called default.conf??????
Ooops, sorry, memory not working; it's been a while. :) I must have copied it from some other colorschemes/*.conf, don't remember which.
Does the lexer for whatever filetype the file is (you didn't say what type AFAICT) distinguish function names as a separate style (for eg C and C++ do not)?
Ahah, light dawns; I was assuming that the lexer would do just that. So now at least I know what needs fixing, though I suspect the lexer might be more daunting than the colour schemes. :-( But I'll give it a look at least!
The documentation doesn't say (anywhere I can see) in which order the multiple .conf files are processed, or which overrides what.
Nothing in the default .confs overrides anything else.
In the filetypes.common there is a section with this comment: [named_styles] # This is the Default "built-in" color scheme which led me to believe that these were the default values that could be redefined by other .conf files; presumably then it must mean only that it is defining the style called "Default", or the one that will be used in the absence of any file type match.
Cheers, Austin.
On Sun, 22 Mar 2020 at 13:43, Austin Green austin.green@orcon.net.nz wrote:
Thanks for responding, Lex.
On Sun, 22 Mar 2020 12:47:56 +1000 Lex Trotman elextr@gmail.com wrote:
I'm calling it Slick; I've created a slick.conf file, copied from the default.conf,
Neither grep nor I can find a file called default.conf??????
Ooops, sorry, memory not working; it's been a while. :) I must have copied it from some other colorschemes/*.conf, don't remember which.
Does the lexer for whatever filetype the file is (you didn't say what type AFAICT) distinguish function names as a separate style (for eg C and C++ do not)?
Ahah, light dawns; I was assuming that the lexer would do just that. So now at least I know what needs fixing, though I suspect the lexer might be more daunting than the colour schemes. :-( But I'll give it a look at least!
These are syntax highlighters, they only distinguish syntax, not semantics or symbols.
It would therefore only be possible if functions are _syntactically_ distinguishable from any other names, but thats not the case in most languages (including C and C++).
The documentation doesn't say (anywhere I can see) in which order the multiple .conf files are processed, or which overrides what.
Nothing in the default .confs overrides anything else.
In the filetypes.common there is a section with this comment: [named_styles] # This is the Default "built-in" color scheme which led me to believe that these were the default values that could be redefined by other .conf files; presumably then it must mean only that it is defining the style called "Default", or the one that will be used in the absence of any file type match.
Yes.
I suppose that you could argue that replacing a default value with an actual value is "overriding", but its not like multiple .conf files can override each other in some order as your question implied.
Cheers Lex
Cheers, Austin. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Sun, 22 Mar 2020 14:03:29 +1000 Lex Trotman elextr@gmail.com wrote:
These are syntax highlighters, they only distinguish syntax, not semantics or symbols.
It would therefore only be possible if functions are _syntactically_ distinguishable from any other names, but that's not the case in most languages (including C and C++).
I take your point, but I guess it depends to some extent on the overall design of the syntax analyser. The editor 'vim', for example, manages to colour functions for Rust, though not for C/C++, while 'SlickEdit' (whose colour scheme I was wanting to copy) manages to do it for functions in C/C++ as well.
Don't think I can find the energy to try to hack Scintilla's lexers right now, and it's not essential, just a 'nice to have' feature.
Cheers, Austin.
On Mon, 23 Mar 2020 at 10:23, Austin Green austin.green@orcon.net.nz wrote:
On Sun, 22 Mar 2020 14:03:29 +1000 Lex Trotman elextr@gmail.com wrote:
These are syntax highlighters, they only distinguish syntax, not semantics or symbols.
It would therefore only be possible if functions are _syntactically_ distinguishable from any other names, but that's not the case in most languages (including C and C++).
I take your point, but I guess it depends to some extent on the overall design of the syntax analyser. The editor 'vim', for example, manages to colour functions for Rust, though not for C/C++, while 'SlickEdit' (whose colour scheme I was wanting to copy) manages to do it for functions in C/C++ as well.
And Visual Studio and VScode, and Eclipse but their colouring isn't just syntax, they fully parse the files in the build context so they can find includes, which means they have seen the declarations of names and then can handle them correctly. Scintilla lexers are (deliberately) just lexers, they do not parse declarations or expressions and they have no API for the symbol parsers in Geany to supply the information. We do (ab)use the keyword lists to get type names coloured differently, but that fails when the same name is used in another context, then it will be coloured as type no matter what it is. That probably would be very slow if all function names were included, and the overlaps would be greater.
Slickedit looks like it does the same as these IDEs to colour functions.
There was an experiment with using Clanglib to supply the colouring, but it needed too many associated changes in Geany and was abandonned.
Cheers Lex
Don't think I can find the energy to try to hack Scintilla's lexers right now, and it's not essential, just a 'nice to have' feature.
Cheers, Austin. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On vim and rust, if the example below (from the Rust manual) does not colour "Color" and "Point" as functions in the "let" lines then it must also be parsing declarations, not using syntax.
``` #![allow(unused_variables)] fn main() { struct Color(i32, i32, i32); struct Point(i32, i32, i32);
let black = Color(0, 0, 0); let origin = Point(0, 0, 0); }
```
Cheers Lex