Mode based themes

[eamonno]

Add the following config options.

theme.normal
theme.insert

The logic is that each of these default to the value of theme but if set override the global theme in that mode. The logic should be pretty straightforward to do as it's just replacing the global theme depending on mode.

You could in theory do the same for selects but my understanding is that since selects can be present in either mode it would be all but impossible to make it behave in a way that works on terminals where you don't get to have extra colours and it would be a lot of extra work for little benefit.

[the-mikedavis]

Parts of the theme like the cursor can already be customized by mode: https://docs.helix-editor.com/master/themes.html#interface

It seems unnecessary to me to be able to change the entire theme on mode switch

[eamonno]

I'm aware of the cursor setting at present and it's certainly useful. My own personal preference is to have a different background in insert mode just so it is very clear visually which mode I'm in. So I could have proposed to add a ui.background.insert setting for that, but maybe someone else would like text to be italic in insert mode, or someone else would just like to change the format of the line numbers, or maybe someone wants to change all those things and more. Maybe some degenerate would even like to have a light mode theme in insert mode and a dark mode theme in select mode. Obviously not all of these will be to everyone's taste but I could see a lot of people having different personal preferences. In particular for anyone streaming or teaching helix having a striking visual difference would be very useful for potential viewers. It would also open up the opportunity for theme designers to create custom insert modes. Since so many themes already have multiple colour variants there should already be plenty options though.

Just having a theme override for insert mode seemed like the least work that provides the most functionality. Especially since themes can already specify a base theme it should make it fairly approachable for anyone to tweak their current theme for insert mode.

There is certainly room for debate over whether having things like the cursor insert formatting should be taken out of the base theme and put into a derived theme but I suspect having to have two versions of every theme would feel a bit bloated. I suspect having that setting in the base theme is probably a bare minimum necessary to make working themes for a modal editor (even if some themes don't use them) but I don't really see any downside in allowing people to tweak the visual distinction between modes to their hearts content if they so choose.

[niknbr]

Also, there is a color-modes config to change the color of the mode indicator based on the mode

[editor]
"color-modes" = true

[Necryl]

I also need this, I know we can theme the cursor, but still I sometimes I am forgetting which mode I am in. The background color will be zero cognitive load indicator that yes, you are in normal mode, or insert mode, or select mode. I think this is more than a just cosmetic feature and something that will truly elevate Helix's experience for me.

But on a lower priority note, if we implement this, I hope we can also add semi-transparent backgrounds, because I like to keep the background transparent. A tinted background color change based on the mode would be perfect.

[patchunwrap]

I think I largely agree with @eamonno in terms of motivation. I used to agree on approach too. But after trying to implement it for a bit.. I now think the best course of action is not to add theme.normal, theme.select, theme.insert options to the config. But instead expand upon and standardize the existing: editor.cursor-shape.insert approach.

On a user side, the theme picker doesn't make sense with a theme per mode approach and possibly becomes config dependent. When you have one theme does it match the current behavior? What about when you have a theme set for each mode? Does it just pick for the current mode? Overwrite all of them?

From a code perspective my approach ended up with a bunch of duplicated code, despite this being one of my concerns going in and me putting my best efforts into avoiding it.

I think with a bit of effort it wouldn't be too hard to simply expand the current behavior and simplify it, and I think it would be a little cleaner since we scatter this logic around the editor and I think it could be all in the theme.rs file. I'm currently working on this and I'll reply back here with a pull request.

[eamonno]

My own thinking on this was that the default insert mode theme would be the current theme with the sole override being to change the cursor shape from block to line. On a longer time themes would no longer need to differentiate between normal and insert mode, they would just have one setting, so you'd have just editor.cursor-shape in each theme and separate themes for each mode.

So you would have your normal theme which would be the anything generic or specific to normal mode, then anything specific to insert mode becomes the insert mode theme which takes everything else from normal and just lets you specify overrides for insert mode. Selecting still runs into the problem that on terminals with limited colour support you can't really override a lot of stuff just on a subset of the screen. That's where the mess lines, do you have to specify fallback select theming for terminals that don't support enough colours?That gets horrible pretty fast.

[patchunwrap]

I had the same thought and actually implemented it that way. I basically created a new struct called "ThemePicker" which had 3 themes inside; normal: Theme, select: Option<Theme> and insert: Option<Theme>. With the same fallback behavior as you suggested.

I didn't even get to limited color support, but you can currently change the color of INS/SEL indicator in the bottom left based on mode so clearly somethings already working. I believe there is already fallback code that just picks base16_default if something goes wrong.

[patchunwrap]

Here is my current pull request for those who want to check it out:
#15214