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.

[romainl]

IMO:

• backward compatibility is a must-have: all colorschemes should "work" in all conditions,
• all colorschemes should work out-of-the-box and require no further tweaking,
• at least a couple of colorschemes should be explicitly colourblind-friendly,
• all colorschemes should follow a set of practical best practices that we should define.

[gagbo]

Maybe you can make a "quick and dirty" tag system, where you have multiple md files (one per theme in the list in the first post) and list the themes currently added with their category (the md would contain only 2 headings and links).

Since you're starting from scratch you can impose it on every new PR, and if someone really wants to have color themes with only xterm 256-color palette (totally random example, of course) they can directly look for the list in that file.

The issue with that solution is that you can't search efficiently for multiple "tags" at once.

Another solution would be to add the "tags" in the header of included colorschemes (if you plan on including the .vim files in the repo). This way, a user can either use github search to look for multiple keywords, or clone the repo and use grep --file-name to list the schemes with the tags they want.

[romainl]

I think we can use the labelling system for that.

[romainl]

Here are the tags I can think of:

• dark background

  background is dark (value is below 50%)

• light background

  background is light (value is above 50%)

• high contrast

  contrast between background and text is high (difference between values is above 50%)

• low contrast

  contrast between background and text is low (difference between values is below 50%)

• high saturation

  colors are highly saturated (color is farther from white, grey, or black)

• low saturation

  colors are not highly saturated (color is closer to white, grey, or black)

• 16color-ready

  supports 16color terminals (common)

• 88color-ready

  supports 88color terminals (rare)

• 256color-ready

  supports 256color terminals (common)

• true colors-ready

  supports true colors terminals (increasingly common)

• suitable for TUI

  works in color terminals

• suitable for GUI

  works in GUI Vim (GVim, MacVim)

• colorblind-friendly

  colors satisfy colorblindness restrictions

Is there something missing?

[romainl]

I think it is not unreasonable to try to offer:

• a full line-up of colorschemes that support everything from 16color to true colors,
• an equal number of "dark" and "light" colorschemes,
• an equal number of "low contrast" and "high contrast" colorschemes,
• an equal number of "low saturation" and "high saturation" colorschemes,
• at least one "dark" and "high contrast" colorscheme that is also "colorblind-friendly",
• at least one "light" and "high contrast" colorscheme that is also "colorblind-friendly".

We need a minimum of 8 colorschemes to cover the whole spectrum.

[gagbo]

The saturation in the colors gives a different feel too :

Big saturation in the colors feel like looking at a rainbow, while low saturation is like looking at a grayscale scheme (you can still have low sat / high contrast - like apprentice or the best example is actually an emacs-theme : modus-operandi and modus-vivendi try really hard for this| low sat / low contrast - like gray on white | high sat / low contrast - like gruvbox light soft variant | high sat / high contrast - like vim-snazzy or vim-gotham)

[romainl]

@gagbo good points, adding saturation to the list.

[sheerun]

I think:

1. All schemes should support both background=light and background=dark (so one can easily switch between daytime vim scheme and nighttime vim scheme)
2. All themes should have good (not high) contrast so they are readable and accessible for most people. Then there can be few themes with high contrast for few people who need it
3. All themes should work in 256 colors with gui colors configured to the same values, so they are suitable for 256 color terminals and gui at the same time (it's very rare there are terminals with less colors available)

[romainl]

1. All schemes should support both background=light and background=dark (so one can easily switch between daytime vim scheme and nighttime vim scheme)

This is a heavy requirement. I don't like it because:

• it makes the design process more complex and more difficult,
• it makes the colorschemes themselves more complex and thus more brittle,
• it subverts the meaning of :help 'background'.

2. All themes should have good (not high) contrast so they are readable and accessible for most people. Then there can be few themes with high contrast for few people who need it

I think we should try this distribution:

• a few low contrast colorschemes,
• many "normal" contrast colorschemes,
• a few high contrast colorschemes.

3. All themes should work in 256 colors with gui colors configured to the same values, so they are suitable for 256 color terminals and gui at the same time (it's very rare there are less available)

Agreed.

[sheerun]

The docs on background say:

When a color scheme is loaded (the "g:colors_name" variable is set)
setting 'background' will cause the color scheme to be reloaded. If
the color scheme adjusts to the value of 'background' this will work.
However, if the color scheme sets 'background' itself the effect may
be undone.

and:

When the |t_RB| option is set, Vim will use it to request the background
color from the terminal. If the returned RGB value is dark/light and
'background' is not dark/light, 'background' will be set and the
screen is redrawn. This may have side effects, make t_BG empty in
your .vimrc if you suspect this problem. The response to |t_RB| can
be found in |v:termrbgresp|.

This means background can be used to customize theme, if theme is implemented correctly, and suggests that themes can automatically select their version (light, dark) depending on whether terminal is light or dark. I think built-in themes should show the way and use these possibilities, even if there will be less of them available

[lunacookies]

Conversely:

Setting this option does not change the background color, it tells Vim what the background color looks like. For changing the background color, see |:hi-normal|.

[gagbo]

For me it makes no sense to force each theme to have a light and dark variant. You can also keep small and lean color files, and ask the users to actually type :colorscheme what-i-want when they want to change.

I don't use Vim that much these days, but as a random theme maker, I can tell that "having to" build 2 palettes is just going to end up with one side being a lot worse and with a lot less effort.

[romainl]

@sheerun the only purpose of &background is to expose how Vim's flawed algorithm thinks the background of the host terminal looks so that Vim chooses its default colours accordingly or force a value when the algorithm fails. It is only meant for colorschemes that don't set a background, like default. Using it to get a "dark" or "light" colorscheme with custom background and all subverts its purpose.

:colo foo_dark and :colo foo_light have the same intended effect as the all-too-common :set bg=dark/:set bg=light hack, but:

• they are not hacks so you don't rely on the side-effects of an unrelated command,
• they keep colorschemes simple and easy to maintain.

[neutaaaaan]

@sheerun

All schemes should support both background=light and background=dark

This is nearly impossible to achieve, the exploitable dynamic range on a light background is extremely limited compared to a dark background.
You can either have an unreadable light version that feels coherent, or two versions that diverge so much they should probably be split into 2 different themes.

This is the best I could come up with when I tried to come up with a light version of Iosvkem , and I gave up on it because I simply could not get good enough separation between colours :

All themes should work in 256 colors with gui colors configured to the same values, so they are suitable for 256 color terminals and gui at the same time (it's very rare there are terminals with less colors available)

The only way this can work is if the themes were made to only use the xterm palette.

It also makes the issue I outlined above significantly worse, as there's no massaging that can be done anymore to get colours to feel right.
Here's the 256c version that colortemplate exports :

Believe it or not, it looked worse when I tried to fiddle with it.

There are only 2 reliable ways to deal with this problem :

• Coming up with the light theme first - much harder than most would assume -
• Settling on 2 or 3 colours + accents like I did for Monosvkem

[sheerun]

Then maybe for each theme we could somehow designate opposite-color version, even if it's another theme

[neutaaaaan]

Honestly, I don't see what the point of arbitrarily associating different themes would be.

Providing useable full-featured low contrast and high saturation light background themes doesn't seem like a possibility to me, especially if we have to pluck the colours out of the xterm palette.
We'd be better off acknowledging that and aiming for things that we know work, even if that means shipping 2 light themes next to 5 dark ones and some generic monochrome dual background thing..

[sheerun]

Okay I guess. So making things concrete what about:

• 2 high contrast dark themes
• 6 normal contrast dark themes
• 2 low contrast dark themes
• 2 high contrast light themes
• 6 normal contrast light themes
• 2 low contrast light themes

So total of 20 themes in which 10 light, 10 dark, 12 normal contrast, 4 high contrast, 4 low contrast

[romainl]

@neutaaaaan all good points.

@sheerun, the exact numbers can't really be set in stone at the moment but those proportions—or something close—seem okay-ish to me. The actual numbers and proportions will, in fine, depend on the proposals we get, though.

[neutaaaaan]

I've thought about it some more, this is going to be pretty long :

Complete backwards compatibility is unrealistic.
Italicized characters cannot be expected to work in a terminal, at all.
It's not part of the featureset of a vt100, there are still botched vt220 emulators or pretend-xterm-clones that get it wrong, GNU Screen doesn't even interpret the escape sequence properly, I've had to have users on mac go through the escape sequence tango in their .vimrc before and the list goes on...
This is not acceptable for a collection of themes that are meant to work perfectly out of the box.

16c

The first 16 colors of a terminal emulator are defined by the terminal emulator, the specific distribution or flavor of insert OS and by the user, in that order.
The only somewhat safe assumption here is that the bottom 8 colors will exist and be different enough to allow us to pretend we're dealing with the standard set of colors.
Colors 8 to 15 can't be assumed to exist at all in case they're the same or only slightly different, and their behavior can't be predicted due to terminal options such as colors 8-15 potentially being an alias for 0-7bold.
Ditch bold characters.

The main issue will be the inevitable overloading of colors within specific contexts.
Bake a dark version, a light version. Ship that. It's a fallback, nothing else.

88c

This is a fairly similar situation, but at least we get bold characters back and we can be sure that red will be red and so on.
Follow the same principles, with the addition of accent colors for ui elements.
It's a fallback, nothing else.

256c and truecolor

Will be bikeshedded to death, and then some more.

The first thing that needs to be settled is whether the truecolor themes should all be restricted to the xterm palette, and if not, whether having different themes for 256c and TC is a possibility or not.
Forcing a truecolor theme to fit into the xterm palette sometimes works mostly ok ( my own themes, lifepillar's version of gruvbox ) but there's no negociating with a 256c palette when things go wrong.

[romainl]

@neutaaaaan

My opinion is that the default colorschemes shouldn't break, no matter where you use them. "Shouldn't break" is not the same as "works" or "works perfectly in the most optimal way", though.

Where Vim doesn't break, built-in colorschemes shouldn't break either.

Italics are indeed not universally available. Falling back to "normal" would probably be acceptable but falling back to "reverse", for example, would break the colorscheme. I would like to test that in as many environments as possible before striking italics out.

I agree that colors 0-15 can't be trusted at all. The color names are only indicative of the platform/app defaults, the indices are different on some platforms, the user can set the value of "Cyan" to any color he wants, etc. but Vim will inevitably be used in 8c or 16c environments so colorscheme authors have to make some assumptions, not to guarantee that their colorscheme works, but to guarantee that it doesn't break.

I, too, have written one of the very few (at the time) colorschemes that used the xterm palette for both cterm*g and gui*g. To me, this creative constraint is a strong guarantee that my colorscheme is going to work in a large number of environments with minimal setup, but I know full well that such constraints can be unwelcome. The xterm palette is very limited (no browns to speak of, for example, everything is over-saturated, etc.) so insisting on such constraints may seem counterproductive.

We need to strike a balance between total creative freedom and neurotic backward compatibility.

[neutaaaaan]

@romainl

My opinion is that the default colorschemes shouldn't break, no matter where you use them. "Shouldn't break" is not the same as "works" or "works perfectly in the most optimal way", though.

My own version of "shouldn't break" is "will always meet some specified baseline behaviour no matter what".
The only reliable way to do that is to forego features that can't be expected to exist everywhere.
To me the only point of shipping, 16c and 88c themes with vim is to soothe the pain of the poor sods working on boxes they cannot update or don't have privileges on : if they could help themselves out of this situation, they would have done so already.

Italic degrading to reverse is a known issue that's predictable, and is what it degrades to on every system I've used or been told about that did not support italicized characters out of the box.
Other gotchas such as colors 8-15 being aliases for bold can be safeguarded against.
The only reliable fallback on boxes that have completely messed up ANSI colours is a monochrome theme, either set t_Co=0 or something that only uses colors for ui elements.

I don't expect anyone to side with me on the issue of whether it should be comprehensive like bruin is, or stripped down to the bone like my own t_co=0 fallback, but there's a pretty hard set list of features that cannot be expected to work, ever, in that context, and to me that's what the baseline should be.

[romainl]

Color support grading:

Grade	0c	8c	16c	88c	256c	True colors
A	Y	Y	Y	Y	Y	Y
B	Y	Y	Y	Y	Y	N
C	Y	Y	Y	Y	N	N
D	Y	Y	Y	N	N	N
E	Y	Y	N	N	N	N
F	Y	N	N	N	N	N

• GUI Vim and many recent terminal emulators are A,
• most terminal emulators are at least B,
• few terminal emulators are C (rxvt, others?),
• lots of older terminal emulators are D,
• IIRC the linux virtual console is E but Vim coul be tricked into thinking it's D,
• dumb terminals and teletypes are F.

Grade A environments are the easiest to support: just use gui* and call it a day.

Grade B environments are not easy to support because the xterm palette is not expressive enough and programmatic conversion from true colors to xterm is lossy by definition and can't be trusted anyway.

Grade C environments are too few. I'm not sure it should be considered relevant.

Grade D environments are often older versions of A or B environments.

Grade E environments are few but I'd consider the Linux virtual console to be pretty relevant.

Grade F environments, well… are ancient history but supporting them should be possible by default.

[lifepillar]

Grade F environments,

For those, one might define a single dumb color scheme supporting only dumb terminals and require any other color scheme to fall back to it, e.g., by including a snippet like this:

if !exists('&t_Co') || empty(&t_Co) || &t_Co <= 2
  runtime colors/dumb
endif

This would alleviate developers from the burden of supporting a corner case and would guarantee that any color scheme would not break in limited environments. Such dumb color scheme might even be put outside colors and invoked with source, to make it invisible to users.

About italics, the approach used by disco.vim to detect italics has worked well for me, but I don't know how foolproof it is. Anyway, I think that one has to be pragmatic, and be happy with color schemes that “do not break most of the time”. Again, a possible approach is to generalize the above and have one “bulletproof” color scheme (or one for dark and one for light background) to fallback to when certain baseline requirements are not met.

[brammool]

@brammool AFAIK, the "definitive" resource about true colors is still https://gist.github.com/XVilka/8346728. Currently reading ncurses's doc about RGB and setaf/setab.

Hmm, the trick to set the color and then read it back seems the most reliable. It's similar to what we do for 'ambiwidth' and recently to check if requesting the cursor properties work. Would need to: - request foreground & background color (like we already do) - set color with RGB and colons - request foreground & background color, check if it matches. - set color with RGB and semicolons - request foreground & background color, check if it matches. - set underline color with RGB and semicolons - request underline color, check if it matches (is this possible?) It's going to be a bit much perhaps. We could only check if setting RGB with semicolons work, it appears they work most widely, even though it's not an official standard. The underline color is clearing the color in xterm. Not sure what other terminals support it or if it's possible to read it back.

…

-- The question is: What do you do with your life? The wrong answer is: Become the richest guy in the graveyard. (billionaire and Oracle founder Larry Ellison) /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[romainl]

It's going to be a bit much perhaps. We could only check if setting RGB
with semicolons work, it appears they work most widely, even though it's
not an official standard.

Testing for semicolons first, then colons, seems to make sense. Maybe after testing for $COLORTERM. I don't know which one is the most involved.

[romainl]

Provisional requirements:

Every colorscheme…

• must be fully functional in GUI Vim and TUI Vim,
• must be functional in environments <= 256c,
• must not depend on scarcely supported features,
• must handle degradation gracefully when a used feature is not supported by the host environment,
• must handle every built-in highlight group.

A few problems are still pending, though:

• poor handling of filetype/plugin-specific highlight groups is still unresolved,
• feature detection is far from an exact science, both within Vim's core and in scripts,
• a vimscript interface for feature detection would be awesome.

In my opinion, a colorscheme that:

• provides gui* attributes for every built-in highlight group,
• provides 256c-ready cterm* attributes for every built-in highlight group,
• provides 16c-ready cterm* attributes for every built-in highlight group,
• doesn't use italic,
• doesn't use strikethrough,
• doesn't use undercurl except in the gui attribute,

is acceptable.

[sheerun]

I'd also vote to not use underline in any form. Current default vim theme does this for highlighting current line. Very annoying. Dimming / highlighting background color looks far better.

[romainl]

I'd also vote to not use underline in any form. Current default vim theme does this for highlighting current line. Very annoying. Dimming / highlighting background color looks far better.

Would this be OK?

• doesn't depend solely on typographic attributes (underline, bold) to provide meaning

[sheerun]

I think so. Typography should be reserved for something like advanced markdown highlighting

[neutaaaaan]

I do agree that bold and underline should only be used when we need to differentiate ui elements, autocompletion choices and so on, not used as part of syntax highlighting per se.
On the other hand, I disagree with changing the background colour as part of syntax highlighting, as I've never seen a dark theme in which it wasn't positively counterproductive, making the wrong things stand out, or making what they're supposed to highlight harder to read.

I'd also like to remind everybody that the 18 themes vim ships with aren't going anywhere, and that we probably don't want to add too many new themes to that list, lest they eventually fall into the same state of disrepair as the old ones.

I'm definitely in favour of only providing one new light colourscheme and one new dark colourschemes for the 8/16/88c versions, all barebones but functional, and then maybe throwing a couple different ones together for 256c and TC. We can't add too much cruft, we can't pull the cruft from existing themes, and we sure don't want people asking on reddit and stackoverflow why the version of popular theme that ships with vim doesn't have italics, or doesn't rewire things around for 3rd party syntax plugins only to be told to install some separate plugin for popular theme.

Speaking of which, we really need to get a definitive list of what can be changed by a theme, and what cannot.
There are elements that Bram doesn't seem to want us to tweak, such as the recent Debug[xxx] elements, but I do rewire them and will keep rewiring them, because they look like absolute crap if I don't.
I'm also on record for not liking how rewired groups "stay empty/point to nothing" when you switch from a slightly customized colourscheme to a bog standard one.

[romainl]

@neutaaaaan…

I'm afraid a hard ban on ctermbg will be more difficult to sell than one on underline. But you have got a point and legibility will certainly be an important criteria when assessing submissions. One thing we can do, is making legibility a requirement, à la WCAG, and making it part of our tests.

About the 18 default colorschemes, they will be overhauled as part of this project so they won't go anywhere. To be honest, I don't expect to find more than a handful candidates.

We can't add too much cruft, we can't pull the cruft from existing themes

We can and we will.

and we sure don't want people asking on reddit and stackoverflow why the version of popular theme that ships with vim doesn't have italics, or doesn't rewire things around for 3rd party syntax plugins

I want to avoid that as much as possible. That's the reason I would prefer to have simple colorschemes that don't require any fiddling. I'm seriously concerned about the eventual impact of this initiative across support channels: I have mild PTSD from the early days of Solarized and I really don't want to reboot that nightmare.

Speaking of which, we really need to get a definitive list of what can be changed by a theme, and what cannot.
There are elements that Bram doesn't seem to want us to tweak, such as the recent Debug[xxx] elements, but I do rewire them and will keep rewiring them, because they look like absolute crap if I don't.

I agree and I've voiced my opinion on that matter earlier. A definitive list of do's and don't's will come soon.

As for your last point about links. This is a painful issue that can't be fixed at the colorscheme-level. It must be fixed in Vim.

[benknoble]

@romainl from solarized, what are you thinking about (installation issues, support my fave plugin issues, or something else)? /just wondering

also, happy to help here as I can

[neutaaaaan]

@benknoble Solarized is an incredibly brittle and overengineered mess, "sold" entirely on hype and pseudo-science, that hasn't been updated in a decade. It doesn't support truecolour, it's impossible to port to 256c, and it's single-handedly responsible for several % of vim-related posts online.

[lifepillar]

I maintain a fork of Solarized that supports true colors, but I agree with you: Solarized has no place in Vim core.

[romainl]

@benknoble, basically what @neutaaaaan and @lifepillar said: it is an abomination that shouldn't exist. Note that the colors themselves of the Vim colorscheme are not in question, it's how it is built that is wrong and that has caused so many issues in the past. UUrgl, you triggered my PTSD…

On a more positive note, a solarized-inspired colorscheme with a palette more compatible with 256c would certainly be acceptable as long as it satisfies our (WIP) requirements.

On a more general note, I want the new colorschemes (and the remakes of the old colorschemes) to be functional out-of-the-box in as many environments as possible without exposing options or requiring any action from the user beyond :colorscheme foobar.

[lunacookies]

@romainl

a solarized-inspired colorscheme with a palette more compatible with 256c

I’m not sure how feasible this is, as IMHO much of Solarized’s characteristic ‘look’ comes from the beige/cream coloured background on the light version, and the deep blue used on the dark version. Neither of these colours has a close enough (in my eyes) equivalent in 256c. Maybe it might be a better idea to focus on adapting colourschemes that are ‘friendly’ to 256c, a quality that definitely requires a background very close to grey.

In particular, I can vouch for remaking Jellybeans, as its colours seem to work especially well in 256c. I actually prefer the 256c version over the True Colour one! Sorcerer/Apprentice and Tomorrow Night are also good candidates.

[romainl]

@arzg Solarized is indeed very non-256c-friendly, which has been the cause of much of the nightmare, so I'm not sure either. 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.

[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.