Here are the popup menus in their current state.

• Are we OK with them?
• Do we need to enforce some kind of consistency?

Blue:

Darkblue:

Delek:

Desert:

Elflord:

Evening:

Industry:

Koehler:

Morning:

Murphy:

Pablo:

Peachpuff:

Ron:

Shine:

Slate:

Torte:

Zellner:

The highlight groups User1 through User9 can be used in the status line. Would it be a good idea to prescribe them the same way we do for g:terminal_ansi_colors, by picking colors from the colorscheme's palette?

We can base it on the colortemplate sample and/or on @neutaaaaan's effort.

What should be put in the header comments?

" Name:         shine
" Description:  Remake of default shine colorscheme
" Author:       Updated by Maxim Kim <[email protected]>
" Maintainer:   Originally maintained by Yasuhiro Matsumoto <[email protected]>
" License:      Vim License (see `:help license`)
" Last Updated: 16.11.2020 11:43:28

Specifically Author and Maintainer?

I think we should leave original maintainer/author and put some url to current https://github.com/vim/colorschemes ?

" Name:            shine
" Description:     Remake of default shine colorscheme
" Original Author: Yasuhiro Matsumoto <[email protected]>
" Maintainer:      https://github.com/vim/colorschemes
" License:         Vim License (see `:help license`)
" Last Updated: 16.11.2020 11:43:28

When 'compatible' is set, 'cpoptions' contains C and according to :help 'cpoptions':

C   Do not concatenate sourced lines that start with a
    backslash.  See |line-continuation|.

Therefore, when sourcing a color scheme file, lines like these throw an error:

let g:terminal_ansi_colors = ['#ffffff', '#0000ff', '#00cd00', '#cd00cd',
      \ '#008b8b', '#0000ff', '#ff1493', '#bcbcbc', '#ee0000', '#0000ff',
      \ '#00cd00', '#cd00cd', '#008b8b', '#0000ff', '#ff1493', '#000000']

Now you might wonder "Why on earth would anyone set 'compatible' in 2021?". Good question. A likely scenario is when starting Vim without a vimrc, for example with vim -u NONE. Without a vimrc, 'compatible' is set by default. So doing something like this this gives an error:

vim -u NONE -c "colorscheme blue"

@brammool would it be possible to add @habamax and @neutaaaaan to the vim/colorschemes project? That would make interacting with them, assigning task and so on easier.

Terminal is defined in some colorschemes but not in others.

This is inconsistent and I think we should decide how to handle that highlight group across all colorschemes.

My opinion: Terminal should be defined explicitly in every colorscheme, either as a link to Normal or on its own.

I don't think other groups are missing, but it's better to double check.

As an aside,it might be better to move all check_colors issues under one thread, but I'll let you decide.

" Load the syntax highlighting defaults, if it's enabled.
if exists("syntax_on")
    syntax reset
endif

Is this still necessary? ":hi clear" already achieves this as far as
I can tell.

":hi clear" causes syncolor.vim to be sourced, which, if syntax is on,
follows this path (condition true):

if !exists("syntax_cmd") || syntax_cmd == "on"

This causes the standard syntax links to be defined with "hi link"
rather than the "hi! link" of "syn reset", but since all groups have
already had their colours cleared, this has the same effect.

E.g.

hi Function ctermfg=1
hi! link Function Error
hi clear

"hi clear" removes the colour and resets the link to Identifier
(tested with Vim 8.2.869).

It looks like delek is the only standard colorscheme that doesn't do an
explicit "syn reset". The others cause syncolor.vim to be sourced twice.

The link ‘The xterm palette’, found on the wiki’s Resources page, is broken. I see this message:

File not found: /v1/AUTH_mw/wikipedia-en-local-public.15/1/15/Xterm_256color_chart.svg

• templates
• guidelines
• online tools

When 'diff' is set, lines with changes should be highlighted with the DiffChange group. With some color schemes, the foreground and background colors for this group are all set to NONE. The changes within the lines are correctly highlighted with DiffText though.

This affects the following color schemes:

• desert
• industry
• murphy

Here is an example with desert.vim, with 'termguicolors' enabled.

Old desert.vim

New desert.vim

Once consensus is reached on a set of colorschemes, how are we supposed to merge them into Vim's tree?

This is a bit of a different request.
Default color scheme for some people like me love it. Unfortunately, in gvim or when termguicolors is on, there are 2 setting which maybe off:

highlight Normal guifg guibg

set background

So I feel that we should create a default light and default dark that set the 2 setting on top of the regular default color scheme.

Questions about this repo:

1. What is the license of these colorschemes?
2. What versions of Vim can these colorschemes support?
3. Will this repo be merged into the Vim repo to replace the existing built-in colorschemes?

Thanks!

Reference: https://help.github.com/en/github/building-a-strong-community/configuring-issue-templates-for-your-repository

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.

I see that the remade colorschemes support millions of colors and 256-color palettes. Are you planning for a fallback for less capable terminals? For instance, when t_Co is 0, Shine looks like this:

By explicitly supporting a fallback, it might look a bit better (this is using _bw.colortemplate from Colortemplate, but I am not necessarily recommending using that):

By "explicitly supporting a fallback", I mean that there could be a b/w color scheme, which other color schemes could source when they detect that there are too few colors. The b/w color scheme could support a wide range of terminals, e.g., with millions or 256 colors it could use shades of gray, with 16 (resp., 8) colors it could use only ANSI 0,7,8,15 (resp., 0 and 7), and without colors it would only define term entries. This would give a somewhat consistent appearance across all color schemes and across all environments (sure, ANSI colors are arbitrary, but usually 0, 7, 8, and 15 are the darkest/lightest). Then, all other color schemes should only define true colors and xterm colors.

Currently :h todo.txt has an entry (line 629):

Include a few color schemes, based on popularity:
http://www.vim.org/scripts/script_search_results.php?keywords=&script_type=color+scheme&order_by=rating&direction=descending&search=search
http://vimawesome.com/?q=tag:color-scheme
Use names that indicate their appearance (Christian Brabandt, 2017 Aug 3)
- monokai - Xia Crusoe (2017 Aug 4)
- seoul256 - Christian Brabandt (2017 Aug 3)
- gruvbox -  Christian Brabandt (2017 Aug 3) (simplified version from
      Lifepillar, 2018 Jan 22, #2573)
- janah - Marco Hinz (2017 Aug 4)
- apprentice - Romain Lafourcade (2017 Aug 6)  remarks about help file #1964
Suggested by Hiroki Kokubun:
- [Iceberg](https://github.com/cocopon/iceberg.vim) (my one)
- [hybrid](https://github.com/w0ng/vim-hybrid)
Include solarized color scheme?, it does not support termguicolors.
- Sanitized version of pablo (Lifepillar, 2017 Nov 21)

It should be fixed to note that there is a separate curated project under vim umbrella that sets guidelines to colorschemes to be included and accepts candidates etc.

@chrisbra, @lifepillar, @romainl

Here's the template for default that I had to make before I could start work on colorschemes derived from it.
I have not fixed any of the glaring inconsistencies in it.

This raises the question of what to do about it, or if we should even do anything about it, as it's technically not really a colorscheme.

:colo notdefault
notdefault.zip

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.

Let's use these for real and find opportunities for improvement.

darkblue (@romainl)

• 16c prefer NONE for Normal fg/bg
• 256c statusline not enough contrast

Will push something soon.

delek (@romainl)

• Error should have cterm=reverse

desert (@romainl)

elflord (@romainl)

evening (@romainl)

industry

koehler

morning

murphy

pablo

peachpuff

ron

shine

slate

torte

zellner

Checks number 7 and 8 in check_colors.vim may be removed, now that vim/vim#4405 has been fixed.

The colors directory can be found here:

$VIMRUNTIME/colors/

It is a historic location with semantic and structural value.

I am wondering which one of these locations is the best for our templates:

$VIMRUNTIME/colors/*templates
$VIMRUNTIME/*templates

I am not super comfortable with adding yet another non-structural directory at the root of $VIMRUNTIME.

This is a copy of this post

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.

The implementation itself is really nothing fancy, I've attached a version I hacked on top of another one of my themes if anyone feels like playing around with it.

None.zip

Steps to reproduce bugs

vim --clean
:view $VIMRUNTIME/vimrc_example.vim " Just to see some syntax highlighting.
:colorscheme blue
:set termguicolors " The highlighting changes to something that isn't blue.
:colorscheme " Output is 'blue' but it clearly doesn't look like blue.
:colorscheme blue " Now correctly looks like the blue colorscheme.
:set notermguicolors " The highlighting changes to something that isn't blue.
:colorscheme " Output is 'blue' but it clearly doesn't look like blue.
:colorscheme blue " Now correctly looks like the blue colorscheme.

This affects most (all?) the remade colorschemes but not the original ones.

Vim version: 8.2.2488
Terminal: Konsole
OS: Kubuntu 20.10

All the builtin colorschemes should be readable in default xterm palette of 16 colors.

• blue.vim
• darkblue.vim
• delek.vim
• desert.vim
• elflord.vim
• evening.vim
• industry.vim
• koehler.vim
• morning.vim
• murphy.vim
• pablo.vim
• peachpuff.vim
• ron.vim
• shine.vim
• slate.vim
• torte.vim
• zellner.vim

Directory names in the output of :terminal ls --color can be hard to read. Directories are dark blue in the color schemes below. Only these four color schemes are affected.

To reproduce:

gvim --clean -c"source C:\Users\gdupras\vimfiles\colors\blue.vim" -c"terminal ls --color"

blue (this one might be borderline acceptable):

evening:

industry:

murphy:

Reference: https://help.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository

We need a way to declare templates for 'no color' support aka Variant: 0.

See #73

@lifepillar fyi