[pyjamafish]

Very interesting to see this, because a few days ago I started using a theme that takes the complete opposite approach: limited hue range, but wide luminance range.

https://github.com/mcchrish/zenbones.nvim

I've found it to be quite practical because it makes keywords easier to pick out, and it allows search matches and diagnostics to stand out better.

[maegul]

Nice work ... really like these!

Personally, I could see myself tweaking the palettes to have a bit more saturation and maybe even have a particular hue palette or have the hues centre around a particular value as you do with the "warm" variant or the "Zenburned" (my fav, and similar to my own manual scheme) in the showcase (https://github.com/mcchrish/zenbones.nvim/blob/main/doc/show...).

Interesting to compare to the the parent post as luminance/brightness contrast based perception is generally better than our colour contrast based perception. There's arguably less information, as colours are categorical (not continuous like brightness) and colours multiplex brightness with hue and saturation, but there are probably some pretty objective metrics in which your kind of scheme would tend to be better in readability.

[solasluaith]

I actually think that in overall perceptual difference, using hue and chroma only is in the same ballpark as luminance only. The relationship between colours would also be totally different as they are arranged on a line vs a circle/polygon in terms of perceptual difference. Would be interesting to compare quantitatively.

Of course that doesn’t tell the whole story because in the end luminance and chroma are not perceived the same way as we tend to associate luminance with more with distance and light and hue and chroma more with the surface properties of the object. (As you mentioned we also tend to treat luminance as a continuous variable and colour as categorical even though both are continuous.) So if you want to use luminance because of this difference, that is a valid, but fundamentally different approach, but I don’t think it would necessarily be superior outright and I’ve tried to make the argument of why I prefer mine.

[edwintorok]

Zenbones allows to define custom color schemes by providing just a few base colours and overrides. You could try creating one based on penumbra to have both lightness contrast and distinct hue.

However note that it is quite difficult to get Zenbones work with existing colorschemes, I tried creating/tweaking one based on Zenburn, but in the end I had to go back to the original Zenburn because Zenbones just wasn't distinguishing enough for the various treesitter highlighting groups.

But perhaps some of the zenbones concepts could be combined with Penumbra in penumbra itself to have another variant in addition to the contrast++ one.

And as mentioned elsewhere there are scientific ways to produce colormaps that work for people with color vision deficiency too, so it'd be nice if that was addressed.

[solasluaith]

Just on the last point, I’d be interested to know what scientific ways to construct CVD-friendly colour maps you mean.

I’m aware of all the continuous colour maps for visualisations and these are pretty much “solved”, but for discrete, categorical ones, the optimisation is trickier and I’m only aware of “good enough” versions rather than fully optimized ones.

[edwintorok]

Colorbrewer2.org has a colourblind safe version. https://peterkovesi.com/papers/ColourMapsForColourBlindIAMG2... talk about designing colormaps in the colorspace of a particular colorblindness (instead of checking whether it is safe after the fact which is non-optimal). My very basic understanding of that is that it'd replace sRGB with a colorspace that represents a particular colorblindess and then uses the same algorithm it'd use on sRGB to obtain a nice scheme in the colourblind space (or at least as much as it is possible given the constraints/reduced gamut).

I am not colourblind though, so I can't vouch for how good these are in practice, but at least there is some systematic thought that went into the process instead of ad-hoc rules.

[solasluaith]

Colorbrewer is safe for CVD but not optimized to be as distinguishable as possible no matter your impairment as far as I’m aware. That’s what I’m trying to do in a different project.

Colormaps have very different constraints due to having to cover a continuous ramp and are therefore also not optimal for categorical palettes. I personally like these the best overall: https://www.fabiocrameri.ch/colourmaps/ but there are many good options at this point.

[solasluaith]

As I said below, I can totally see how taking the opposite approach of making different keywords more or less salient could be just as valid, if you prefer this over having an even, “text-like” appearance. I’m not aware of a fully coloured theme that quantitatively does this but it’s probably out there.

I’m not a fan of this almost fully monochrome theme though, by limiting yourself to differences mostly along one axis, you quickly run into to issues where adjacent values are hard to distinguish. I would argue that since we are trying to encode categories, it’s a mistake to completely forego chroma and hue.

[solardev]

This looks really cool!