Language specific syntax highlighting/theming

[chtenb]

Generic syntax highlighting themes may not fit all languages perfectly. For example, a theme optimized for C# might not work well for Javascript, because C# has types while Javascript has not. Can we allow theme adjustments per language to accomodate dealing with this? If necessary I can work out a specific use case, but I think the reasoning is clear enough. Other text editors, like VSCode, TextMate, Sublime, etc support this by simply having a language moniker at the end of each highlighting scope, like keyword.storage.cs.

Tangentially related issues:

• Language specific keymaps #4501
• Language-specific configuration #836

[pascalkuthe]

I don't see a usecase here. We have seperate captures for seperate concepts so the fact that a theme has highlighting for types doesn't matter when dealing with JavaScript because those theme scopes are simpy ignored.

You are free to create theme variants for seperate languages but I don't see us adding that to core.

[chtenb]

I'll try to elaborate more. Below you see two screenshots of the same theme, but you will notice that they have a completely different color balance. In this particular case that is caused by the fact that Yellow/Orange was chosen to highlight types. Since JavaScript does not have types, this color completely dissappears, changing the color balance of the theme. A theme designer could compensate for this by using Orange for a subset of javascript keywords, to restore the color balance.

In other text editors this is a common practice, and you will see themes advertising the list of languages for which the author "optimized" the theme.

[danillos]

I agree, I built a Helix theme for the Ruby language in mind, it looks great to me. But for others like XML and HTML I would like to optimize it.

I think only theme creators can see how it is bad.

[chtenb]

Some more examples of language specific theming usecases include

• JSON nestedness highlighting as described in Match simultaneous scopes when theming #6201
• CSV column highlighting akin to https://github.com/mechatroner/vscode_rainbow_csv

Note that for these two features more is needed than just language specific theming. Either simultaneous scopes, or more probably custom highlighting queries with scopes like column1.

@pascalkuthe How would one provide themes for separate languages today? I've not been able to find a way to do this, it seems one can only have one global theme at a time.

[pascalkuthe]

yeah I just don't think that we need to support this in core at all that seems quite niche to me and something that could be handled by the plugin system when that is available. In other editor themes are always global property too and a rust develpor may use a theme that might be a bit more tweaked for rust but really that is a personal choice and not something that needs to be in core.

The more advanced stuff you linked can't be implemented right now regardless of how you configure your theme so that seems orthogonal anyway. The color choice provided by the theme would then just have generic scopes for rainbow colors (like in #2857) and the generation of the rainbow colour would be handled by TS queries (which is generally where any language specific highlighting is supposed to come from)

[chtenb]

Sure, if the plugin system will be able to handle this stuff, seems like a valid choice to me. I do like the fact that the general scopes provided by helix are fairly limited and streamlined. It feels a lot less polluted and convoluted than in other text editors I've written themes for. Sure, it's less powerful, but if plugins can account for that we're in a good spot. I'm looking forward to the plugin system, so I can port my VSCode themes :)

[chtenb]

Possibilities I currently see to achieve this:

1. Have language scopes, like source.js, source.cs, supplement the other scopes. (Common place in other text editors.)
   • Requirement: Support simultaneous scopes Match simultaneous scopes when theming #6201
2. Have scopes end in a language moniker like keyword.storage.cs. (Common place in other text editors.)
3. Have theme variants for each separate language.
   • Requirement: Support language specific configuration Language-specific configuration #836

Option 1 and 2 could be added in a plugin system if that system allows supplementing syntax highlighting queries.
Option 3 could potentially be tedious for the end user, because their config would need to include switches for all different languages in the theme.
Option 1 is probably the cleanest. It's an orthogonal design and allows for more powerful and concise scope expressions, like source.js keyword, which according to Option 2 would have to iterate all nested possibilities to select all javascript keywords: keyword.js, keyword.storage.js, keyword.control.js, .... This is highly unergonomic and prone to breakage with grammar/highlighting query updates.

[TeriyakiBomb]

Option 1. is ideal, this is how it works elsewhere. I maintain a theme for a few editors and would love to make a version for Helix, but so far the inflexibility is very limiting. I add support for a bunch of languages to maintain consistency, I can't currently do this with helix :(

[meowgorithm]

Just chiming in here to say that this is a very important one for me as well.

General purpose themes never fit all languages well, and I get a lot of value out of being able to hone and adjust themes to better fit the languages I spend time with. In many cases I have distinctly different themes for different languages in order to be able to quickly understand what language I'm looking at with a glance.

In NeoVim with Treesitter I'm able to target Go with rules like function.call.go and I was surprised to find this wasn't the case with Helix.

(@chtenb, nice to see you here!)