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

[chrisbra]

This is a followup to #1665 and the related issues. Unfortunately not much happened and we still haven't decided on nice new colorschemes to distribute with Vim. I apologize it took so long, but apparently deciding on which colorschemes to use is not so easy 😕

So in order to move this topic forward, I'd like to ask colorscheme writers who want their colorschemes distributed with Vim to mention this here.

All others, please indicate by voting if you like this particular scheme.

However, in order to distribute your colorscheme, the following points should be taken into account:

• It should pass the check_colors.vim test script
• If your colorscheme only works for a particular background setting, please indicate so (bonus points for supporting light and dark values ;)
• Please provide screenshots for terminal (non termgui setting) and gui settings, so we can judge how it looks like with 256color terminals and in the gui. I assume the termgui setting will make the console look like the gui version).
• Should come with a bit of documentation in case there are configuration settings
• We should be allowed to distribute it (obviously)
• Please provide a category under which this falls. We already kind of decided on:
  • dark
  • light
  • colorful
  • subtle
  • grayscale/monotone
  • (others, if it does not fit into the above)?
• Bonus points for nice coloring in the MSDOS console mode and dumb 16 color terminals or even the powershell window (Please indicate so!)
• Bonus points for being actively developed/maintained and actively supporting the community
• Bonus points for clear and easy understandable code

Now I realize the categories are kind of personal taste, but we only intend to package a couple of nice colorschemes. So this is basically to limits the number of colorschemes to be distributed so that users that install Vim are not easily overwhelmed by the amount of packaged colorschemes and provides an indication to the users what kind of colorscheme this is.

In any case, you will always be able to install additional colorschemes using packages (e.g. the well-known https://github.com/flazz/vim-colorschemes).

I hope we find some nice looking colorschemes that we can include with Vim.

[chdiza]

Should come with a bit of documentation in case there are configuration settings

I think that nothing that has configuration settings should be accepted.

[EgZvor]

Some sort of "colorblind" category is missing.

[chrisbra]

I think that nothing that has configuration settings should be accepted.

Hm, I don't think this is a hard requirement. As long as this is documented this might be okay. Even better would be, if the default looks sane to most people ;)

[chrisbra]

Some sort of "colorblind" category is missing.

That is actually a good suggestion. Are there any good colorschemes for colorblind people?

[EgZvor]

I'm not the one to tell, but https://github.com/romainl/vim-dichromatic seems well researched and I installed it just in case. And this one https://github.com/PierreCapo/voir.vim is made by a colorblind person.

[romainl]

I submit Apprentice:

• dark background
• low-contrast
• handles &background on its own
• supports GUI
• supports true colors terminal emulators
• support 256color terminal emulators
• obviously doesn't look the same in <256color terminal emulators but still works
• supports the Windows console
• doesn't need any configuration
• doesn't require any specific documentation
• actively maintained
• generated via an easy to edit ERB template
• no complicated logic, easily hackable
• generated code is as simple as can be

Some code in MacVim:

Some code in iTerm, with TERM=xterm-256color:

Some code in mintty, with TERM=xterm-256color:

Some code in iTerm, with TERM=xterm, using the Tango color palette:

Some code in iTerm, with TERM=xterm, using a custom palette derived from Apprentice:

Some code in the Windows console, with TERM=cygwin, using a custom palette derived from Apprentice:

As for check_colors.vim compliance:

• The "init" check is too naïve: it checks for this and only this:

  hi clear
  if exists("syntax_on")
    syntax reset
  endif
  

  so it rejects this perfectly valid code:

  hi clear
  
  if exists("syntax_on")
    syntax reset
  endif
  

• The requirement that debugPC and debugBreakpoint shouldn't be defined makes no sense. The default highlighting is an eyesore in every colorscheme but default and colorscheme authors shouldn't be barred from redefining it.

• The highlight groups flagged in the "filetype" check are defined/linked for a very good reason: providing a uniform experience across filetypes. Complying with this check would have only one consequence: making my colorscheme look unpolished.
  Yes doing so can break other colorschemes but that has been a long-lasting issue with :hi def … that should be fixed at a low level because it can't be fixed at a high level. Colorscheme authors must use :hi link … if they want to provide a consistent experience, therefore the underlying linking mechanism should handle this in a better way.
  Every reasonably popular colorscheme does that because it is currently necessary and every reasonably popular colorscheme gets issues opened about linking issues for which there is no known solution. So, IMO, either the underlying issue is fixed or you won't be able to include any popular third-party colorscheme.

---

Copied from #1964 (comment):

@brammool, how do you suggest we figure this out?

• Everyone and their dog has a favorite colorscheme, sometimes their own. This will create noise.
• Judging by popularity alone would be unwise as the most popular colorschemes have lots of issues and generally require a lot of tweaking and reading to work.
• We should probably "design" the default colorscheme roster: "we want a mix of monochrome/popular clones/fancy colorschemes" or "we want the same as usual but modernized" or… This would help us choose.
• We should strive to keep things simple: :colorscheme foobar should be all that's needed to enable a built-in colorscheme and users shouldn't have to go through individual help pages to configure such a simple feature.
• Likewise, GUI-only or CLI-only or truecolors-only colorschemes should be avoided in my opinion.
• Support is something to consider, too. Popular colorschemes like Solarized or Gruvbox have been the cause of an incessant stream of support requests on every support channel for years. While redirecting users to proper channels is an easy task, it is very time-consuming. Including popular colorschemes will add a lot of noise to every support channel.

[shmup]

Some sort of "colorblind" category is missing.

That is actually a good suggestion. Are there any good colorschemes for colorblind people?

It's possible that the collection of colorschemes themselves would play nicely to the various forms of colorblindness. I'm not informed in this area, but I see that there are four common groupings of color processing (including Normal):

I'd be curious what existing default schemes people use that are colorblind, not to mention new ones

[lifepillar]

The requirement that debugPC and debugBreakpoint shouldn't be defined makes no sense.

I am responsible for adding that check. The rationale is the same as for the filetype check: debugPC and debugBreakpoint are plugin-defined highlight groups and, as such, defining them in a color scheme may wreak havoc when switching to a different color scheme.

Regarding this and the filetype check: the check_colors script checks adherence to “best practice”, and currently, filetype- and plugin-specific highlight groups are not best practice: from a user's standpoint they introduce a bug (wrong colors after switching color schemes). One may decide to ignore such warnings (after all, they are just that), but they should be kept, IMO, at least until #4405 is resolved.

Other than that, I agree with @romainl's points. I'll add this: if each post in this thread is like @romainl's, this is going to become a loong thread ;)

Finally, a proposal. Instead of managing things via a GitHub issue in the main Vim repo, how about joining forces? I mean: create a vim/colorschemes repo and give access to a (small?) task force of developers willing to contribute new color schemes specifically designed for Vim, according to the goals outlined by @brammool. People would submit their proposals there (one proposal per issue rather than a long thread), and the task force would evaluate them. Instead of pulling color schemes as they are, the task force would be in charge of adapting the best color schemes according to commonly agreed guidelines, guaranteeing consistency and deliberating on choices such as whether/how to permit filetype highlight groups, whether the color schemes should be allowed to have options, etc. The original submitter of an accepted color schemes might become part of the task force or relinquish its control on the derived color scheme to the task force.

[romainl]

The requirement that debugPC and debugBreakpoint shouldn't be defined makes no sense.

I am responsible for adding that check. The rationale is the same as for the filetype check: debugPC and debugBreakpoint are plugin-defined highlight groups and, as such, defining them in a color scheme may wreak havoc when switching to a different color scheme.

Barring colorscheme authors from defining the visual properties of publicly accessible highlight groups doesn't make sense, especially given :h hl-debugpc.

Regarding this and the filetype check: the check_colors script checks adherence to “best practice”, and currently, filetype- and plugin-specific highlight groups are not best practice: from a user's standpoint they introduce a bug (wrong colors after switching color schemes). One may decide to ignore such warnings (after all, they are just that), but they should be kept, IMO, at least until #4405 is resolved.

From a colorscheme author's point of view, highlighting the < in <div… in a color different from the div is unacceptable and I will keep linking filetype-provided highlight groups, as instructed in the documentation.

I'll add this: if each post in this thread is like @romainl's, this is going to become a loong thread ;)

Not sorry for having an informed opinion and expressing it.

I mean: create a vim/colorschemes repo and give access to a (small?) task force of developers willing to contribute new color schemes specifically designed for Vim, according to the goals outlined by @brammool.

I agree with vim/colorschemes but @brammool hasn't set any specific goal AFAIK.

[neutaaaaan]

I am responsible for adding that check. The rationale is the same as for the filetype check: debugPC and debugBreakpoint are plugin-defined highlight groups and, as such, defining them in a color scheme may wreak havoc when switching to a different color scheme.

:h :Termdebug gives a result even without packadd Termdebug. I'd argue that it's much more like enabling something shipped with vim by default than installing a 3rd party plugin, and that for the 2 or 3 lines it'd add to themes, it's worth adding.

What really ought to be fixed is the way vim falls apart when you switch from a customized theme to a more conservative one.
Then we could actually talk about best practices - not adding tons of unnecessary crap - instead of calling preserving the status quo so nothing breaks if you sneeze wrong best practices.

[lifepillar]

I'll add this: if each post in this thread is like @romainl's, this is going to become a loong thread ;)

Not sorry for having an informed opinion and expressing it.

The above wasn't meant as a personal attack, but I see that it was expressed poorly. What I meant is, as there may potentially be many replies, and each reply should provide the detailed information you have provided, this thread may become very long. That's why I was suggesting that a dedicated repository might be a better idea.

but @brammool hasn't set any specific goal AFAIK.

Not in this thread, but see #2573 (comment) and #2573 (comment).

[brammool]

> Some sort of "colorblind" category is missing. That is actually a good suggestion. Are there any good colorschemes for colorblind people?

There are many kinds of color blindness, thus it might be difficult to have one "color-blind" colorscheme. It might work to have a high-contrast colorscheme, that works for many kinds of problems with color. It's something that looks awful to normal people, but much more readable to people with different kinds of eye problems.

…

-- Life is a gift, living is an art. (Bram Moolenaar) /// Bram Moolenaar -- [email protected] -- http:https://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http:https://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http:https://www.Zimbu.org /// \\\ help me help AIDS victims -- http:https://ICCF-Holland.org ///

[brammool]

@brammool, how do you suggest we figure this out?

We tried to select colorschemes before, and we didn't get to a conclusion. Also, discussing all goals and all color schemes with all users it going to be an awful lot of communication. How about we select a committee, a small group of Vim uses who care about this, have some ideas and can judge color schemes. Perhaps create a system to judge the quality of color schemes and give feedback to authors. This avoids that we have a worldwide discussion that will quickly die because it contains too many opinions, ideas and noise.

…

-- Q: What do you call a fish without an eye? A: fsh! Q: What do you call a deer with no eyes? A: no eye deer. Q: What do you call a deer with no eyes and no legs? A: still no eye deer. /// Bram Moolenaar -- [email protected] -- http:https://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http:https://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http:https://www.Zimbu.org /// \\\ help me help AIDS victims -- http:https://ICCF-Holland.org ///

[romainl]

Some sort of "colorblind" category is missing. That is actually a good suggestion. Are there any good colorschemes for colorblind people?
There are many kinds of color blindness, thus it might be difficult to have one "color-blind" colorscheme. It might work to have a high-contrast colorscheme, that works for many kinds of problems with color. It's something that looks awful to normal people, but much more readable to people with different kinds of eye problems.

There are three types of color blindness. Of the two colorschemes mentioned earlier, voir and dichromatic, dichomatic addresses all three by using a palette defined by previous academic research, and voir is made by a color blind vimmer though I'm not sure what type of color blindness he has.

I believe we can have colorschemes that works for color blind and non-color-blind users.

[romainl]

@brammool, how do you suggest we figure this out?

We tried to select colorschemes before, and we didn't get to a conclusion. Also, discussing all goals and all color schemes with all users it going to be an awful lot of communication.

Agreed.

How about we select a committee, a small group of Vim uses who care about this, have some ideas and can judge color schemes.

It looks like at least some of those users have auto-appointed themselves.

Perhaps create a system to judge the quality of color schemes and give feedback to authors.

The workflow suggested by @lifepillar sounds good to me:

1. create a vim/colorschemes repository (maybe with some access granted to that small group you mentioned)
2. write an extensive README.md laying out the goals and rules
3. let colorscheme authors open pull request (maybe with a template mentioning check_colors.vim)
4. discuss each submission in its own thread

This avoids that we have a worldwide discussion that will quickly die because it contains too many opinions, ideas and noise.

Agreed.

[trevordmiller]

I'd like to submit Nord from @arcticicestudio: https://github.com/arcticicestudio/nord-vim

[romainl]

@brammool, do you think we could move forward on this subject?

[brammool]

Romain Lafourcade wrote:

@brammool, do you think we could move forward on this subject?

I haven't seen much activity on this, unfortunately.

…

-- hundred-and-one symptoms of being an internet addict: 215. Your mouse-clicking forearm rivals Popeye's. /// Bram Moolenaar -- [email protected] -- http:https://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http:https://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http:https://www.Zimbu.org /// \\\ help me help AIDS victims -- http:https://ICCF-Holland.org ///

[romainl]

I haven't seen much activity on this, unfortunately.

What activity are you expecting exactly?

@lifepillar suggested the creation of a repo under the vim organization, where the commitee you mentioned could discuss individual pull requests as per agreed-upon guidelines. To me, it looks like the repository creation is clearly out of @lifepillar's hands or mine while we definitely have the embryo of a commitee, here.

All we need to start is a clearly identified repository and a README.md.

[brammool]

Closing in favor of PR #9795