Colorize Vim coloschemes values

[mtcs]

Hi,

I find the plugin great, but there is a place where I think it would really shine, vim colorscheme. It already colorizes the RGB strings, but I think that with little effort, it would also be great to color the cterm=XXX directives. It would be a great help on edditing colorschemes.

[ap]

That’s a reasonable desire. And it’s probably partially doable.

There are problems though. Those are palette indices, and the palette is entirely up to the terminal emulator.

The RGB cube and the grayscale ramp tend to be hard-coded in the emulator and emulators seem to agree closely enough on the exact values… so those should be safe-ish to add.

But the lowest 16 colours are completely user-configurable in every GUI terminal emulator I’m aware of. And I’ve seen many colorschemes that actively require you to configure your terminal to something very different from the standard 16 colours.

Of course in console Vim that particular problem can be avoided by self-reference: ctermbg=231 can just be linked to a highlight group with ctermbg=231. But there is a different problem instead: there is no way to know whether the foreground colour should be black or white… or, for that matter, which index is black or white (though I suppose one could just use the grayscale ramp for that and be fairly confident that at least that part will work).

Sorry that life is complicated and seemingly really simple desires are not easy to fulfil. 😊

I’ll keep thinking about this, and of course if you have suggestions for approaching any of these issues, I’m all ears. I just can’t promise very much. 😊

[mtcs]

Well, I think just coloring ctermbg and ctermfg backgrounds when using 256bit colors would be good enough. I don't think that it should match both foreground and background. Just being able to see the color corresponding to palette indices would be great.

[ap]

What do you mean by “when using 256bit colors”? (I know you mean 256 colours and not 256-bit colours – I’m not referring to the typo.) You mean this only needs to work in console Vim, but not in GUI Vim?

I don't think that it should match both foreground and background.

I think you misunderstood what I was talking about. What I mean is that the text in a colour highlight has to have suitable contrast against its background. So for dark background colours, the plugin sets the foreground colour to white, and for light background colours it sets it to black. That way you don’t get unreadable combinations like “black on near-black” or “white on off-white”. However, picking white or black for the text in this way requires ⓐ knowing what RGB the background colour is and ⓑ knowing a suitable palette index for “white” and “black”. But the grayscale ramp is a reasonably safe choice for ⓑ so it mostly comes down to the ⓐ issue. And I’m not aware of any approach for solving that…

[mtcs]

What do you mean by “when using 256bit colors”? (I know you mean 256 colours and not 256-bit colours – I’m not referring to the typo.) You mean this only needs to work in console Vim, but not in GUI Vim?

I mean the code for 256 colors(its not not 256bit, its 8bit), which are not usually altered by the terminal. The code from \e[38;5;198m which is specified as ctemXX=198 in VIM. I think that should work on both term and gui. But the simpler approach is better, just interpret the code as it is and color the background of the number. Maybe even the base 8 terminal colors could be highlighted, if the terminal/gui changes it, the user should be aware of it.

I think you misunderstood what I was talking about. What I mean is that the text in a colour highlight has to have suitable contrast against its background. So for dark background colours, the plugin sets the foreground colour to white, and for light background colours it sets it to black. That way you don’t get unreadable combinations like “black on near-black” or “white on off-white”. However, picking white or black for the text in this way requires ⓐ knowing what RGB the background colour is and ⓑ knowing a suitable palette index for “white” and “black”. But the grayscale ramp is a reasonably safe choice for ⓑ so it mostly comes down to the ⓐ issue. And I’m not aware of any approach for solving that…

I think the plugin could color only the background of the number, not the foreground. The foreground color could be done the same way as you do in the RGB. Or you could color the background on ctermbg and the foreground on ctermfg and fall in that problem. I am in favor of the simpler solution, always visualize the color in the background, It is not ideal, but I think it works.

like the image bellow:

[ap]

I think that should work on both term and gui.

GUI Vim always uses the RGB colours. To show ctermfg=76 in green in GUI Vim, the plugin must know that colour 76 corresponds to #80D340. It can probably rely on fixed such colours for the RGB cube and grayscale ramp, but definitely not for colours 0–15.

I think the plugin could color only the background of the number, not the foreground.

That is not possible. Your own example shows why:

like the image bellow:

Uhm, that image doesn’t show that… it shows the exact opposite! 😊 It shows a black on green highlight, whereas the normal text colour is white. So the text colour is changed – and you can see why: white on green would not be very readable. So the plugin uses black on green instead.

[ssokolow]

But there is a different problem instead: there is no way to know whether the foreground colour should be black or white… or, for that matter, which index is black or white (though I suppose one could just use the grayscale ramp for that and be fairly confident that at least that part will work).

You could just...

1. Pretend that terminals don't allow configuring colors and hard-code the contrast relationships as they exist in the defaults.
2. Trust that users will preserve the contrast relationships the default colours held, rather than reconfiguring every terminal application that wants to use color. (Assuming they even support it)
3. Provide an option variable to to turn this feature off for those users who are niche enough to violate that assumption.

[ap]

No, I could not.

Pretend that terminals don't allow configuring colors and hard-code the contrast relationships as they exist in the defaults.

Every single terminal I can think of does, and there are no standard defaults. Terminals all ship a roughly comparable palette for the first 16 colours, but their exact RGB values vary quite a bit. Some terminals ship with a very bright and candy-coloured palette, some ship a more muted pastel rendition of those general colours. Some ship with a bunch of profiles that all differ visibly in their 16 base colours.

Bottom line is there is not even a set of RGB values for the base 16 colours that I could ship that would look right “if the user hasn’t reconfigured their terminal”.

Trust that users will preserve the contrast relationships the default colours held, rather than reconfiguring every terminal application that wants to use color. (Assuming they even support it)

That would simply be an incorrect assumption. Solarized would be a famous example, just to name one off the top of my head, but I’ve seen countless others.

Provide an option variable to to turn this feature off for those users who are niche enough to violate that assumption.

They are not niche. In the grand scheme of Vim users, maybe, but they are nowhere near niche enough to simply disregard.

---

But thinking about this from a year’s remove, I think it would be reasonable to make a few assumptions, even if not those particular ones.

1. The RGB cube and grayscale ramp aren’t configurable in several terminals I know about and are very unlikely to be reconfigured even where they can be – so assuming fixed contrast relationships is fine for those parts of the palette.

2. The 16 base colours need different treatment.

   I do not want to ship highlights that will look bad – so I will not include highlights for those for terminal Vim. But I can include a configuration in the docs that would work under the default palette, so users can opt in.

   However, GUI Vim does not have a palette anyway, so for GUI Vim I can include what would basically be an illustrative set of default-ish RGB values for the 16 base colours (and since I know their RGB values, the contrast question is answerable). Even so, it needs to be possible disable them, for users who want to override them (or just simply disable them).

And of course it needs to be possible to disable the whole thing.

I think this is a set of choices that works reliably enough that I would be comfortable shipping it as a default. The RGB cube and grayscale ramp are almost certain to work, so users can have support for those without having to do anything, since they will probably-never have to fight the default. For the 16 base colours, users who are likely to have to fight the defaults (i.e. terminal Vim) have to opt in to them; while users who are more likely to benefit from defaults (i.e. GUI Vim), but are somewhat likely to want to opt out (because they are editing a colorscheme for a customised terminal), can do so. I think that’s the closest I can get to users getting maximum benefit without ever thinking about it.

---

Update:

The default highlighting for the 16 base colours ought to include defaults for both terminal and GUI. It’s the configuration flag’s default value that should implement the split treatment, by depending on whether the plugin is running under terminal Vim (false) or GUI Vim (true). Then setting the flag would be an easy way to enable default highlighting even in the terminal, while resetting it would turn off the default highlighting everywhere.

This rewards users who stick to a version of the standard palette by making it easy to opt into support for it – without copy-pasting as much stuff to vimrc as tinkerers will need.

[ssokolow]

That sounds reasonable.

Certainly more reasonable than I would be, given my perspective that worrying about people editing their terminal colors is like worrying about people going nuts with their LCD monitor's OSD menus. (I'll make a reasonable effort but, if they violate the basic sanity assumptions of the execution environment in a way that's clearly caused by their changes, it's up to them to live with the results of their actions.)