Define a mission

[romainl]

This repository has been created in the context of the following issues opened by @chrisbra in Vim's issue tracker:

• New colorschemes
• Poll: Colorscheme Writers, please indicate nice colorschemes that you want to have distributed with Vim

As part of the discussion, users @lifepillar and @romainl (me) proposed to turn the process of choosing what colorschemes to include in Vim into its own project, separate from the main repo.

The goal of this repository/project is to:

• reduce the noise in the main issue tracker,
• handle individual submissions separately,
• discuss guidelines properly,
• offer useful resources for colorscheme authors.

Noise reduction

We have our own repository, now, so we should ensure that further discussion on the subject are redirected here.

Submissions

Submissions should take the form of templated pull requests, made by the colorscheme authors themselves, not fans.

We should set up a CI environment to run check_colors.vim and/or equivalent tools against each submission.

Guidelines

Here are some of the questions we have to answer:

• What kind of colorschemes do we want to include in Vim?
• Do we want to replace the current default collection?
• Can we take this opportunity to modernise the current default collection?
• Do we want the new collection of colorschemes to follow some kind of structural pattern like seasons, or palettes, etc.?
• What criteria should we favour?
• Is colour blindness a blocking criterion for inclusion?
• Is performance important?
• More TUI? More GUI? 16? 88? 256? True colors?
• What responsibility do we want to take with regard to the technical support of those colorschemes?
• What licences are compatible with Vim's?

Resources

Creating a colorscheme is not easy and creating one that works reasonably well can be tough. The wiki should help colorscheme authors find useful resources.

[xero]

im curious of the end game. is this going to be a supplemental to vim, or the new offical color schemes collection distributed with the core?

either way, im excited to help

[romainl]

im curious of the end game. is this going to be a supplemental to vim, or the new offical color schemes collection distributed with the core?

either way, im excited to help

The end game is to refresh the default lineup with a selection of "new" colorschemes like your sourcerer or my apprentice ;-).

There are a few things to figure out, though, before we open a proper "call for colorschemes", some of them being listed above.

Beside introducing more third-party colorschemes, I would also like to modernise the current collection so that we don't end up with an unbalanced mix of old unmaintained crap and shiny new jewels.

[xero]

i was also thinking about what constitutes a "good enough" theme. i would assume support for both console and gui versions. what about extent? is the plan to only support core vim highlight groups or will submissions with a wider array of support for plugins going to be allowed as well?

[lifepillar]

Thanks for taking care of this!

My two cents on some of the points you raise:

Do we want to replace the current default collection?

I'd say no. Perhaps, deprecate those color schemes that do not have an active maintainer. Keeping a color scheme in Vim's distribution is cheap, after all.

Can we take this opportunity to modernise the current default collection?

I had reworked the current color schemes several months ago: https://github.com/lifepillar/vim8-colorschemes. Depending on the direction that is taken regarding how color schemes should be developed, you might find it a useful starting point (or not). Note that you only need to look at the files in the colors folder. Feel free to do whatever you want with that code, including ignore it.

Do we want the new collection of colorschemes to follow some kind of structural pattern like seasons, or palettes, etc.?

Possibly an unnecessary constraint.

What criteria should we favour?

I'd strive for (a) simplicity, and (b) what people likes. The two goals cannot probably be achieved at the same time, in which case I would favor simplicity for long term benefits (what people likes changes all the time). Do almost anyone wants Gruvbox in Vim? Ok, someone open a pull request for a color scheme with the Gruvbox palette, but forget the original codebase (or my own “Gruvbox 8” variant): too bloated, too slow. Do you insist that you need four different contrast levels for each background and a dozen knobs to tweak it to your liking? Go and download a color scheme plugin.

Incidentally, for this reason I would also carefully consider how to name color schemes: I would favor original, unique, names to avoid clashes with users' plugins.

Is colour blindness a blocking criterion for inclusion?

I'd say no, but it would be nice if at least some (if not most) color schemes would be color-blindness aware. This has emerged in the previous discussions as something that quite a few people would appreciate. Generally speaking, I think that this repo should point developers to standards such as ISO-9241-3, W3C, or other technical resources, and actively encourage submissions that satisfy minimal usability criteria.

Is performance important?

I feel like I'll be in a minority, but for me it's a definite yes (also related to the simplicity mentioned above). I have found that the fastest way to load a color scheme is to write it as exemplified by the reworked color schemes I have linked above. But some people may find that way of writing color schemes too hard to maintain. Maybe there's a middle ground.

More TUI? More GUI? 16? 88? 256? True colors?

Tough question :) IMO, at least two options should be provided. In decreasing order of importance: true colors (mandatory), 256 colors (mandatory), 16, 8, 2. How many 88-color terminals are there?

What licences are compatible with Vim's?

I think that if it's going to be included in Vim it should ship under Vim's license.

[romainl]

@xero In my opinion, built-in colorschemes should work equally well wherever Vim works so they should cover everything from 16color to GUI. As for support for plugins, there are unsolved issues with linking that may make it a bit complicated.

[romainl]

@lifepillar thank you for commenting. I think we are in agreement on every point.

My criteria:

1. compatibility
2. simplicity
3. performance
4. accessibility

[gagbo]

Incidentally, for this reason I would also carefully consider how to name color schemes: I would favor original, unique, names to avoid clashes with users' plugins.

I'm looking forward to "Gravbux" and "Silorized" :D

About accessibility, an emacs user created a colorscheme where his 1st priority was to be compliant with the highest level of accessibility WCAG AAA which he interpreted as making sure that the contrast between any foreground color and background color is always at least 7:1 (you can check contrast here ). I think it'd be a great addition somewhere (although I suppose the "default" theme is already good enough)

But some people may find that way of writing color schemes too hard to maintain. Maybe there's a middle ground.

Looks like templating tools like https://github.com/romainl/vim-rnb might be useful

[romainl]

Looks like templating tools like https://github.com/romainl/vim-rnb might be useful

I think lifepillar/vim-colortemplate is a better fit as it could eventually be bundled with Vim itself.

As I see it, none of today's most popular colorschemes satisfies the (emergent) list of requirements. This means that their authors will have to switch to our "officially recommended" templating tool anyway. It sounds daunting and restrictive but I believe that a uniform UX will help improve the whole ecosystem.