Colorschemes to consider for inclusion ?

[neutaaaaan]

I was doing some research to gather a list of candidate colorschemes for potential inclusion, based on a list I gathered from these two threads 1 2 and a few other colorschemes that I think are relatively popular, and it dawned on me that all these suggestions had been made years ago.

There are some unavoidable modern classics in there, but there are also other colorschemes that I haven't seen mentioned nearly as much during the interval. I'm also pretty unaware of what the new hotness is these days, so I believe polling the community for suggestions would be a good idea, especially now that we're relatively confident we won't get stuck in another yearslong rut.

So far I've been classifying colorschemes in 4 categories:

1. Straight (im)ports, that are already entirely 256c safe.
2. Close enough approximations in 256c, with little to no rewiring of groups or elements under the hood. These should probably be given derivative names to avoid causing confusion (ie: jellybeans -> gummybears).
3. Colorschemes that, as part of their core identity, have colors that have no close enough matches in 256c, or that extensively rewire groups and/or specific elements.
4. The absurd, brittle mess that solarized is.

Only categories 1 and 2 are really considered for inclusion, but I'm sure there are outliers in the third category that could be made to work.

[romainl]

You could probably scrape a handful of r/vim threads and get a good idea of what is hot but would that be helpful?

Imagine we get gruvbox at #1, now what? The project has been on life support for many years so how do we convince the author/maintainer/ghost to rewrite it with colortemplate and, very important, without all the fancy options? Is that something we should do ourselves like for the OGs if the author is MIA? What do we do if the author refuses the rewrite? Etc.

Here is a proposal : write clear guidelines and then publicize, with the help of Bram, a formal call-for-colorschemes directed toward authors, not users. Interested authors could then open templated PRs and "the community" could vote and comment in the thread.

[neutaaaaan]

Imagine we get gruvbox at #1, now what? The project has been on life support for many years so how do we convince the author/maintainer/ghost to rewrite it with colortemplate and, very important, without all the fancy options? Is that something we should do ourselves like for the OGs if the author is MIA? What do we do if the author refuses the rewrite? Etc.

I never even considered giving the OG authors sole ownership of the versions supposed to be shipped with vim: I refuse to allow what we just went through to happen again.

Figure out good candidates, get a feel for the changes that will have to be made, ask the OG authors if they're ok with it.
If they aren't, move on to the next one.
If they are, and want to take care of that version, great. If 5 years down the line we lose track of them, there are other maintainers attached to that vim-specific colorscheme.

Here is a proposal : write clear guidelines and then publicize, with the help of Bram, a formal call-for-colorschemes directed toward authors, not users. Interested authors could then open templated PRs and "the community" could vote and comment in the thread.

This would basically rule out including any of the modern classics as most of them receive little maintenance to begin with, and the effort of templating them probably appears far greater than it actually is.
I'm also wary of waving colorschemes in on the basis of an ad-hoc popularity vote on a platform only regularly visisted by 0.001% of the already tiny minority of vim users who'd care to participate.

[romainl]

I never even considered giving the OG authors sole ownership of the versions supposed to be shipped with vim: I refuse to allow what we just went through to happen again.

I agree.

Figure out good candidates, get a feel for the changes that will have to be made, ask the OG authors if they're ok with it.
If they aren't, move on to the next one.

OK. FWIW, here is a list of popular colorschemes I put together from the linked threads and a bunch of r/vim threads from the last 4 years:

• gruvbox
• gruvbox-material
• seoul256
• lucario
• pencil
• papercolor
• alduin
• base2tone (a collection)
• jellybeans
• tomorrow
• molokai
• monokai
• vim-janah
• sola-fucking-rized light & dark
• nord
• badwolf
• zenburn
• vim-two-firewatch
• ayu
• dracula
• kolor
• vividchalk
• nova
• everforest
• onedark
• iceberg
• tempus
• tokyonight

I will also add a couple of tasty old ones I really like:

• busybee
• mustang (yes, a deviantart link)

A few observations:

• Lots of dark colorschemes, here, and the silly overnight success of "dark mode" makes me think the gap is going to widen.
• Lots of colorschemes designed with little care for lesser terminals. This means progressive degradation.
• Lots of colorschemes with dependencies, complications, etc.

[habamax]

These should probably be given derivative names to avoid causing confusion (ie: jellybeans -> gummybears).

I would use OG names as much as possible. OFC, we should ask authors if they are ok if we include "reworked" colorscheme of their own with the same name.

[neutaaaaan]

Using OG names is a bad idea, there's always going to be some deviation between the authors' repository, what we can actually provide, and what end users are actually exposed to through their distribution.

[romainl]

I agree with @neutaaaaan we might use the original name only if explicitly allowed to. Our gruvbox (if any) is going to be so different from the original gruvbox that we might call it groovebox or something.

[romainl]

If we can't get all or most of the most popular third-party colorschemes, maybe we can try to identify trends like "cold", "warm", "hearthy", "two tones", etc and address them?

Like… nord, iceberg, and pencil are all examples of what I would call a "cold" trend that we could ride by creating colors/icicles.vim, an archetypal "cold" colorscheme with blues and cyans and whites and grays, effectively occupying the "cold" niche.

Everforest, alduin, seoul… would be examples of a "hearthy" trend.

Etc.

[habamax]

What are most popular in the bucket?

• Cold: Nord?
• Warm: Gruvbox?
• Hearthy: ?
• Two tones: ?

What would be dracula in to?

[romainl]

I would place dracula in a broad "neon" category, with tokyonight and onedark.

The most popular "Hearthy" one would be seoul256, I guess. Not sure about "two tones". Those were suggestions anyway, if we can come up with better categorization methods let's do it.

[romainl]

So… we just merged zaibatsu, a "neon/cyberpunk/vaporware/etc."-inspired colorscheme.
We also have…

• the dual-background retrobox for gruvbox fans,
• quiet for those who want their syntax highlighting minimal,
• and the "vibrant and playful" wildcharm.

What now?

[neutaaaaan]

I've tried making a "cold" colorscheme very loosely based on iceberg and [nord] (https://github.com/arcticicestudio/nord-vim) but could never get enough separation between colors for such a colorscheme to make sense to me.

Linking to screenshots of the 24bit versions of those colorschemes to illustrate one major point: they use 3 or 4 (if you're feeling generous) colors and overload their semantic meaning to hell and back.

Even if we were to try and expand their basic palette, I don't think it'd be possible to ship a cold colorscheme that wouldn't completely fall apart in situations that heavily mix highlighting groups. It'd be much worse than the back and forth that happened with Zaibatsu's PreProc and Identitfier colors.
The 8 and 16c versions would also have absolutely no relation whatsoever with the gui/256c versions as far as color semantics go.

On the other hand, how do we feel about the idea of including this ? It's kind of cold, and I've been told the author is only a minor pain in the ass to deal with.

[romainl]

The reduced palette issue is already present in the originals and they are nonetheless pretty popular. Would it it really be out of the question to ship such a colorscheme?

Extreme palette reduction is common and people seem to like it: nord would be an example but the biggest one is of course solarized, with all those crazy "neutrals" in ANSI8-15.

[neutaaaaan]

I just threw this together based on the 256c palette of iceberg:

It shall be noted that I hate grey backgrounds with a passion (I'm fine with tinted backgrounds), and that I paid no attention to how I assigned the colors. Here's the corresponding terminal palette

I think it's important to ship colorschemes that respect the purpose of the main 6 highlighting groups, but I'm willing to try and fold groups that in my experience tend to serve a "structural" purpose more than an acutely semantic one when using vim's default groups. If statement, preproc and type were the same color we could wring out more resolution out of at least 2 subgroups.

[habamax]

What now?

I guess we have enough changes to create PR and continue with future-to-be-included colorschemes.

[habamax]

And one of the "cold-bluish" colorschemes would be nice to include. Although I am not sure how to create/port one that would be good enough, to be honest.

[habamax]

I guess whatever we decide here should be aligned first with @brammool.

[brammool]

The main reason (from my POV) for a separate colorschemes repo, is that I don't need to get involved in discussing all the details of colors. I hope you manage to work out problems with existing colorschemes, make updates, try them out, etc. And then we select a good subset to include in the distribution. Enough choice to satisfy most users, but not too many to avoid taking a long time to try out until a nice one is found.

Selecting a colorscheme is very much a personal preference and can easily lead to long discussions about what would be better. Starting with the choice of a light or dark background. And whether dim or bright colors are desired. etc. We should end up with a diverse selection, avoiding schemes that look very similar.

[neutaaaaan]

That's effectively what we've been using this repository for.

We can't do much about shipping too many colorschemes per se because of the 17 legacy ones padding the selection, but if my count is right this pr would put the total amount of colorschemes shipped as part of the runtime to 24 which I think is acceptable as the more recent ones were made to cater to specific needs or niches (monochrome, low contrast, gruvbox analog, dracula analog, iceberg analog and so on).

I believe we're pretty much done, give or take sliding another couple colorschemes in further down the line as new trends emerge, so right now the only blocker I can think of for the pr previously mentioned is how to handle overrides that are part of the visual identity of a colorscheme. I hope I'll be able to convince @habamax to bring back the overrides for syntax files that ship as part of the runtime, but he has the final say on that.

[habamax]

I can restore those links (with exception to what doesn't come out of the box with vim), @neutaaaaan.

PS:
Links are restored with exception to elixir and ALE. All links are to existing in vim runtime syntax elements.

Not sure about updating PR yet, is there a decision on colorschemes inclusion?

And a broader set of questions we will need to have answers for (just for other people who would like propose a new colorscheme for inclusion): what is the process? Is the door closed and the only purpose of a repo is to "look for a new highlight groups in vim_dev and take care of them in existing colorschemes"?

What we have defined here as a mission might not reflect reality.

[neutaaaaan]

I suppose I should have phrased "we're pretty much done" differently. What I meant is that I think we're done with this cycle of activity.
We're bound to bump into interesting colorschemes out there that don't have close matches in the runtime. I'm thinking about beginning work on a jellybeans analog myself, but I expect I'll be fairly busy during the next few weeks, if not months.
We'll eventually acrue another small set of colorschemes that fill a niche, some hopefully provided by users, and go through another cycle.

In the meantime, we could fall back into maintenance mode, be on the lookout for new groups, or the odd group that may need adjustments in specific colorschemes.
Maybe even look into some of the adjacent issues we ran into during the last couple years, such as the lack of explicit hl-color groups for syntax file to link their semantically correct hardcoded colors against, or a deep dive into the various syntax files that blindly hardcode colors and typographic elements.