[Feature Request] Customization of individual semantic highlighting colors.

[BlueCyro]

Description of the problem

Hello there, I've been poking around at geany and it seems like a pretty nifty editor. However, I noticed that there doesn't seem to be any way to define color customizations for individual LSP-provided tokens.

Though you can whitelist tokens with the semantic_tokens_types and define a color with semantic_tokens_type_style, the latter configuration option appears to blanketly highlight all semantic tokens with the same color, which isn't exactly what I'm looking for.

Feature request

I would like the ability to customize the color for each allowed semantic token type in a similar manner to how the semantic_tokens_type_style option works, but with the ability to define a style for each individual token.

This would allow much more thorough customization of what each semantic token looks like in the editor, and would sidestep the need to write an entirely new custom lexer when the LSP highlighting is readily available.

Alternatives I've tried

I poked around quite a bit with the built-in lexers that provide basic syntactical analysis of the file, but the granularity just isn't there.

I even tried defining some of the semantic tokens in the color/file type configs, but nothing works. All allowed semantic tokens are just colored by a single semantic color. :/

My goal is to use this for C#, and it actually works fairly well with csharp-ls, however I'm one of those big babies coming from VSCode, and I have a very particular highlighting setup that jives with my mind. :P

I specifically want to customize the way struct is colored separately from class, and I want to change the way enum is colored separately from enumMember. Generalized semantic token color customization would solve this nicely.

Geany has somewhat surprised me with how competitive it is with other types of editors given that it came out while I was in kindergarten, and having granular customization of semantic coloring from the LSP would go a long way into making it all that much more of a real alternative to most other modern editors.

[techee]

Though you can whitelist tokens with the semantic_tokens_types and define a color with semantic_tokens_type_style, the latter configuration option appears to blanketly highlight all semantic tokens with the same color, which isn't exactly what I'm looking for.

Would it be sufficient to have a fixed number (say 5) of such styles? The configuration would look like

semantic_tokens_types1=type
semantic_tokens_type_style1=17;#00007f;255;255;17
semantic_tokens_types2=class
semantic_tokens_type_style2=18;#AA007f;255;255;17
semantic_tokens_types3=enum
semantic_tokens_type_style3=19;#BB007f;255;255;17
semantic_tokens_types4=interface
semantic_tokens_type_style4=20;#CC007f;255;255;17
semantic_tokens_types5=struct
semantic_tokens_type_style5=21;#DD007f;255;255;17

I think having a fixed number of configurable styles should be sufficient; I think it would still be best to leave styling of strings, comments, numbers, etc. to Scintilla as this will be fastest and Scintilla should do a good job here.

Geany has somewhat surprised me with how competitive it is with other types of editors given that it came out while I was in kindergarten

Please don't remind us about how old we got :-)

[BlueCyro]

Though you can whitelist tokens with the semantic_tokens_types and define a color with semantic_tokens_type_style, the latter configuration option appears to blanketly highlight all semantic tokens with the same color, which isn't exactly what I'm looking for.

Would it be sufficient to have a fixed number (say 5) of such styles? The configuration would look like

semantic_tokens_types1=type
semantic_tokens_type_style1=17;#00007f;255;255;17
semantic_tokens_types2=class
semantic_tokens_type_style2=18;#AA007f;255;255;17
semantic_tokens_types3=enum
semantic_tokens_type_style3=19;#BB007f;255;255;17
semantic_tokens_types4=interface
semantic_tokens_type_style4=20;#CC007f;255;255;17
semantic_tokens_types5=struct
semantic_tokens_type_style5=21;#DD007f;255;255;17

I think having a fixed number of configurable styles should be sufficient; I think it would still be best to leave styling of strings, comments, numbers, etc. to Scintilla as this will be fastest and Scintilla should do a good job here.

Geany has somewhat surprised me with how competitive it is with other types of editors given that it came out while I was in kindergarten

Please don't remind us about how old we got :-)

I imagine it would be less work for you, and I don't want to seem overly greedy... But I think you should be able to customize all of the semantic tokens.

Not to compare apples to oranges, but VSCode, Sublime Text, Neovim, etc. allow defining per-token color overrides for semantic highlighting outside of their main theming, which allows I and many others to heavily customize the way semantic highlighting looks on each token per-language, and also per-project as well.

I reckon it's probably a bit more work to do that, but if I'm knocking at your door for some color customization, it's very likely some other dev is gonna come in and ask for more token slots. This is a common frustration I've encountered that has driven me up the wall in other LSP-supporting editors that also don't support all tokens (Kate, KDevelop, Helix, etc.), and I think geany-lsp could stand out here by filling in the gap.

Scintilla as this will be fastest and Scintilla should do a good job here.

I know scintilla is fairly good, but in my experience, simple syntax-based highlighting just doesn't cut it, especially if the lexer for a given language isn't up to snuff with what the programmer is looking for. The LSP might be slower too, but I'd rather be able to fully customize how complete the syntax highlighting is rather than have to budget some limited number of tokens. Speed means nothing to me if I can't fully make up for any shortcomings of a given lexer.

It wouldn't strictly look awesome in the config, but if I could define multiple scintilla foreground styles in semantic_tokens_type_style by just repeating the already-existing pattern, that would be good enough for me. This would affect each token defined in semantic_tokens_types in the order that they appear in the semicolon-separated list. That way, you could keep most of how that option works, but when the type style pattern repeats, apply it to the next token.

E.g:

semantic_tokens_types=struct;class
Colors struct first, class second

semantic_tokens_type_style=19;#00FF00;255;255;17;20;#0000FF;255;255;17
Struct is pure green, class is pure blue

Again, it's not super pretty, but that logic could(?) be simpler to implement than defining a bunch of new config keys, and would allow the granularity that other mainstream editors provide, which is a very modern (and extremely nice) convenience.

Thank you for such a prompt response by the way. Given that VSCode is slowly creeping AI into stuff, the quiet "here is your editor, have fun :)" nature of geany is very appealing. I really just need to be able to customize all of the semantic tokens though, and it would jump considerably in probability that it becomes my new main IDE. No other editor does this in a way that isn't extraordinarily complicated (Neovim) or doesn't overdraw other editor features from lack of proper upstream support (Sublime Text)

My hunt has been rather... Desperate if you can't tell, lol.

[techee]

I imagine it would be less work for you, and I don't want to seem overly greedy... But I think you should be able to customize all of the semantic tokens.

Maybe 5 was a too low number and, in principle, I could use an "unlimited" number of styles but I'm still limited by Scintilla here. Colorization of semantic tokens is a bit hacky because Scintilla doesn't allow normal colorization of tokens on top of what the lexer does. One way is to inject semantic tokens as keywords into Scintilla but then you have e.g. for always colorized the same way no matter whether it appears as a for loop keyword or as a variable in the document. The other way is to misuse indicators:

https://scintilla.org/ScintillaDoc.html#Indicators

These are normally meant to be used e.g. for highlighting syntax errors and most of them have a form of some underline or a box around the text when you look at the available styles (I already use some for diagnostic messages in the plugin and Geany itself and other plugins use some too). Each used indicator has its index, general purpose ones from 8 to 31 - I use indices 13-16 for diagnostic messages and 17 for semantic tokens (I don't remember exactly why I started from 13, possibly because I saw lower indices used in other plugins or Geany). So in any case, you will end up with a limited number of indicator indices and, as a result, limited number of styles you can use (I don't know, maybe if you get to the IME range, things will still work, i haven't tried that).

Also notice that there's no boldface indicator (as Neil explained me, he wants to support also proportional fonts and because of internal implementation of Scintilla, indicators must not change the layout of the text which boldface indicators could do). So it won't be possible to support boldface styles.

semantic_tokens_types=struct;class
Colors struct first, class second

semantic_tokens_type_style=19;#00FF00;255;255;17;20;#0000FF;255;255;17
Struct is pure green, class is pure blue

I'd rather avoid that, it's not really that hard to have it implemented the way I suggested and this way you'd also waste "precious" indicator indices in case you could reuse a single color for multiple semantic tokens.

Thank you for such a prompt response by the way.

You have been rather lucky ;-). Geany isn't being developed in some super-active manner as we cannot devote so much time to it. So better to assume that things will stay the way they are rather than expect that all you suggest gets implemented. That said, this particular issue makes sense and shouldn't be too hard to implement so I might try to do something about it soonish.

Also, I implemented the LSP plugin "my way" (which was also reasonably minimalistic in terms of lines of code and maintainability of the result) without looking much at what other editors do so I possibly missed many useful things other editors implement. You seem to have tried many editors and it's always good to know what could be improved - please feel free to open new issues if you are aware of anything (without any guarantee I'll implement it though).