-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Colorschemes to consider for inclusion ? #197
Comments
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. |
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.
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 agree.
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:
I will also add a couple of tasty old ones I really like: A few observations:
|
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. |
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. |
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. |
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 Everforest, alduin, seoul… would be examples of a "hearthy" trend. Etc. |
What are most popular in the bucket?
What would be dracula in to? |
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. |
So… we just merged zaibatsu, a "neon/cyberpunk/vaporware/etc."-inspired colorscheme.
What now? |
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 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. |
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. |
I just threw this together based on the 256c palette of 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 |
I guess we have enough changes to create PR and continue with future-to-be-included colorschemes. |
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. |
I guess whatever we decide here should be aligned first with @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. |
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. |
I can restore those links (with exception to what doesn't come out of the box with vim), @neutaaaaan. PS: 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. |
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. 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. |
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:
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.
The text was updated successfully, but these errors were encountered: