Define guidelines

[romainl]

Colorschemes can be grouped according to several criteria:

• light background versus dark background
• low contrast versus high contrast
• 16color versus 88color versus 256color versus true colors
• dumb versus smart
• basic versus exhaustive
• colourblind-friendly versus colourblind-hostile
• etc.

We can have several approaches:

• come up with a representative and balanced collection
• favour forward compatibility (GUI-only because true colors is the future)
• favour backward compatibility (must support everything from 16color to TC)
• make colourblind-friendliness a hard need
• favour maintainable colorschemes
• etc.

[lunacookies]

@romainl

My comment was meant to convey the idea that choosing colorschemes will not primarily be a matter of taste. Ideally, I would prefer to leave "I like this colorscheme" and "I don't like this colorscheme" outside of the equation.

Cool, thanks for the heads-up. Is there any place where the choice of colourschemes to be included can be bike-shedded? :)

[sheerun]

Closest color is probably 230, but you can define both guibg and closest ctermbg in themes. Vim automatically enabling termguicolors if terminal supports gui colors would be helpful for sure

[lifepillar]

Just for the sake of completeness, https://github.com/jan-warchol/selenized appears to rectify some Solarized issues, while keeping the “solarized” look-and-feel. The discrepancy between terminal and GUI colors is unavoidable, however.

As a more general remark: it is possible to quantify the difference between RGB colors and their xterm approximations. Rather than a narrow constraint on the background color, a more general guideline might be defined along these lines: “color schemes where the maximum discrepancy between a GUI color and the correspondent xterm color is greater than N are not acceptable”.

This has the advantage of being objective and measurable. It might be even included in check_colors.vim as an automated test. My Colortemplate plugin has a function to compute such difference, which you might use.

[neutaaaaan]

@arzg jellybeans does a decent amount of rewiring under the hood, we'd run into the issue romainl and I mentionned the other day. So does the version of Tomorrow Night you linked to.

People already have expectations about how they're supposed to look that we wouldn't be able to match. Generally speaking, it's a symptom of bad design, but there's also the issue of vim highlighting falling apart when you switch from one of those customized themes to a more standard one.

@sheerun you might want to look at this

[lunacookies]

@neutaaaaan

I’d agree that this kind of nonstandard linking and highlighting of filetype-specific highlight groups doesn’t belong in a colourscheme that’s meant to be shipped with Vim. What I meant was less that those colourschemes should be copied verbatim, but rather that they could be ‘remastered’ by reusing their palettes and the assignment of the colours from these palettes to standard Vim highlight groups.

In fact, a couple of months ago I created a new colourscheme that uses Jellybeans’ 256-colour palette, but excludes the rest of Jellybeans’ complexity. I did the same for Tomorrow Night, but with True Colour instead of 256. I only used them for a few days before switching back to what I was using at the time, so they definitely need some polishing, but they might still be useful. I haven’t released either of them ‘properly’, but I have created a Gist including both of the Colortemplate files.

[neutaaaaan]

@arzg I could see that working for themes that don't do too much sleight of hand. I'm just afraid that Joe Schmoe will expect some behaviour no matter what.

[sheerun]

I've actually spent quite some time to design function that converts rgb color to xterm equivalent and minimizes visual distance. For sure it can be improved but at least it's O(1):

N = []
for i, n in enumerate([47, 68, 40, 40, 40, 21]):
    N.extend([i]*n)

def rgb_to_xterm(r, g, b):
    mx = max(r, g, b)    
    mn = min(r, g, b)

    if (mx-mn)*(mx+mn) <= 6250:
        c = 24 - (252 - ((r+g+b) // 3)) // 10
        if 0 <= c <= 23:
            return 232 + c

    return 16 + 36*N[r] + 6*N[g] + N[b]

Maybe Vim could even do such conversion for gui colors internally

[lunacookies]

@neutaaaaan

@arzg I could see that working for themes that don't do too much sleight of hand. I'm just afraid that Joe Schmoe will expect some behaviour no matter what.

Maybe this could be remedied by changing the name entirely from the original, rather than modifying it slightly. This slight modification has led to confusion amongst some font patching projects – at least one person has mistakenly identified ‘Fura Code’ as a typo (the original font is called ‘Fira Code’).

[neutaaaaan]

@arzg sunitized and gummybears :p

[lifepillar]

Maybe Vim could even do such conversion for gui colors internally

I don't think that it's a good idea, in general. In my experience, when you start approximating colors, there are cases where you want to use an xterm color that is not the most visually similar to its RGB counterpart. So, it is better to let the developer choose the xterm colors.

That said, an automatic fallback for when the color scheme does not specify suitable terminal colors might be possible. I might be wrong, but IIRC Neovim does something like that.

[neutaaaaan]

I've worked a bit on that pure monochrome theme that would allow people to ignore a broken environment, and keep :syntax on without having to resort to setting t_Co=0 which quite frankly is the visual equivalent of vogon poetry.

Not defining anything but bold/underline/reverse and letting vim use your terminal foreground and background colors works just fine.
I'm relatively satisfied with what I've put together, although my own preference is to only highlight things that I feel I want to know, rather than try to be complete. There is some annoying overlap here and there, but it's fairly minimal.

Any comments ?

[romainl]

Any comments ?

Could you open a dedicated issue or pull request? That way we will be able to discuss this more freely.

[Flamekasai]

Soo any final guidelines?

In my opinion is enough with the following:

• Compatibility with 16 256 and true colors.
• A template or pattern to follow for all colorschemes.
• What text effects are allowed. ( Bold, underline, reverse in my opinion are the most compatible and enough for themes ) ( The use of nocombine for compatibility shake can be interesting. still learning about it, not a lot of documentation )
• Possible customization by the user but not required for the theme to work. ( Optional )

[romainl]

@Flamekasai no official guidelines yet. I have three weeks of freedom next month, which I will devote to this project.

As for your list, it seems to be very close to what we are getting at. nocombine is too new for me, too, I haven't had a chance to play with it.

[Flamekasai]

Oh okey, don't forget to enjoy free time too.

I'm really excited for this project and to help when everything is ready to start.