search

vim / colorschemes

colorschemes for Vim
279 stars 23 forks source link

Define guidelines #6

Open romainl opened 4 years ago

romainl commented 4 years ago

Colorschemes can be grouped according to several criteria:

We can have several approaches:

romainl commented 4 years ago

IMO:

gagbo commented 4 years ago

Maybe you can make a "quick and dirty" tag system, where you have multiple md files (one per theme in the list in the first post) and list the themes currently added with their category (the md would contain only 2 headings and links).

Since you're starting from scratch you can impose it on every new PR, and if someone really wants to have color themes with only xterm 256-color palette (totally random example, of course) they can directly look for the list in that file.

The issue with that solution is that you can't search efficiently for multiple "tags" at once.

Another solution would be to add the "tags" in the header of included colorschemes (if you plan on including the .vim files in the repo). This way, a user can either use github search to look for multiple keywords, or clone the repo and use grep --file-name to list the schemes with the tags they want.

romainl commented 4 years ago

I think we can use the labelling system for that.

romainl commented 4 years ago

Here are the tags I can think of:

Is there something missing?

romainl commented 4 years ago

I think it is not unreasonable to try to offer:

We need a minimum of 8 colorschemes to cover the whole spectrum.

gagbo commented 4 years ago

The saturation in the colors gives a different feel too :

Big saturation in the colors feel like looking at a rainbow, while low saturation is like looking at a grayscale scheme (you can still have low sat / high contrast - like apprentice or the best example is actually an emacs-theme : modus-operandi and modus-vivendi try really hard for this| low sat / low contrast - like gray on white | high sat / low contrast - like gruvbox light soft variant | high sat / high contrast - like vim-snazzy or vim-gotham)

romainl commented 4 years ago

@gagbo good points, adding saturation to the list.

sheerun commented 4 years ago

I think:

  1. All schemes should support both background=light and background=dark (so one can easily switch between daytime vim scheme and nighttime vim scheme)
  2. All themes should have good (not high) contrast so they are readable and accessible for most people. Then there can be few themes with high contrast for few people who need it
  3. All themes should work in 256 colors with gui colors configured to the same values, so they are suitable for 256 color terminals and gui at the same time (it's very rare there are terminals with less colors available)
romainl commented 4 years ago
  1. All schemes should support both background=light and background=dark (so one can easily switch between daytime vim scheme and nighttime vim scheme)

This is a heavy requirement. I don't like it because:

  1. All themes should have good (not high) contrast so they are readable and accessible for most people. Then there can be few themes with high contrast for few people who need it

I think we should try this distribution:

  1. All themes should work in 256 colors with gui colors configured to the same values, so they are suitable for 256 color terminals and gui at the same time (it's very rare there are less available)

Agreed.

sheerun commented 4 years ago

The docs on background say:

When a color scheme is loaded (the "g:colors_name" variable is set) setting 'background' will cause the color scheme to be reloaded. If the color scheme adjusts to the value of 'background' this will work. However, if the color scheme sets 'background' itself the effect may be undone.

and:

When the |t_RB| option is set, Vim will use it to request the background color from the terminal. If the returned RGB value is dark/light and 'background' is not dark/light, 'background' will be set and the screen is redrawn. This may have side effects, make t_BG empty in your .vimrc if you suspect this problem. The response to |t_RB| can be found in |v:termrbgresp|.

This means background can be used to customize theme, if theme is implemented correctly, and suggests that themes can automatically select their version (light, dark) depending on whether terminal is light or dark. I think built-in themes should show the way and use these possibilities, even if there will be less of them available

lunacookies commented 4 years ago

Conversely:

Setting this option does not change the background color, it tells Vim what the background color looks like. For changing the background color, see |:hi-normal|.

gagbo commented 4 years ago

For me it makes no sense to force each theme to have a light and dark variant. You can also keep small and lean color files, and ask the users to actually type :colorscheme what-i-want when they want to change.

I don't use Vim that much these days, but as a random theme maker, I can tell that "having to" build 2 palettes is just going to end up with one side being a lot worse and with a lot less effort.

romainl commented 4 years ago

@sheerun the only purpose of &background is to expose how Vim's flawed algorithm thinks the background of the host terminal looks so that Vim chooses its default colours accordingly or force a value when the algorithm fails. It is only meant for colorschemes that don't set a background, like default. Using it to get a "dark" or "light" colorscheme with custom background and all subverts its purpose.

:colo foo_dark and :colo foo_light have the same intended effect as the all-too-common :set bg=dark/:set bg=light hack, but:

neutaaaaan commented 4 years ago

@sheerun

All schemes should support both background=light and background=dark

This is nearly impossible to achieve, the exploitable dynamic range on a light background is extremely limited compared to a dark background. You can either have an unreadable light version that feels coherent, or two versions that diverge so much they should probably be split into 2 different themes.

This is the best I could come up with when I tried to come up with a light version of Iosvkem , and I gave up on it because I simply could not get good enough separation between colours : light_tc

All themes should work in 256 colors with gui colors configured to the same values, so they are suitable for 256 color terminals and gui at the same time (it's very rare there are terminals with less colors available)

The only way this can work is if the themes were made to only use the xterm palette.

It also makes the issue I outlined above significantly worse, as there's no massaging that can be done anymore to get colours to feel right. Here's the 256c version that colortemplate exports :
light_256 Believe it or not, it looked worse when I tried to fiddle with it.

There are only 2 reliable ways to deal with this problem :

sheerun commented 4 years ago

Then maybe for each theme we could somehow designate opposite-color version, even if it's another theme

neutaaaaan commented 4 years ago

Honestly, I don't see what the point of arbitrarily associating different themes would be.

Providing useable full-featured low contrast and high saturation light background themes doesn't seem like a possibility to me, especially if we have to pluck the colours out of the xterm palette. We'd be better off acknowledging that and aiming for things that we know work, even if that means shipping 2 light themes next to 5 dark ones and some generic monochrome dual background thing..

sheerun commented 4 years ago

Okay I guess. So making things concrete what about:

So total of 20 themes in which 10 light, 10 dark, 12 normal contrast, 4 high contrast, 4 low contrast

romainl commented 4 years ago

@neutaaaaan all good points.

@sheerun, the exact numbers can't really be set in stone at the moment but those proportions—or something close—seem okay-ish to me. The actual numbers and proportions will, in fine, depend on the proposals we get, though.

neutaaaaan commented 4 years ago

I've thought about it some more, this is going to be pretty long :

Complete backwards compatibility is unrealistic. Italicized characters cannot be expected to work in a terminal, at all. It's not part of the featureset of a vt100, there are still botched vt220 emulators or pretend-xterm-clones that get it wrong, GNU Screen doesn't even interpret the escape sequence properly, I've had to have users on mac go through the escape sequence tango in their .vimrc before and the list goes on... This is not acceptable for a collection of themes that are meant to work perfectly out of the box.

16c

The first 16 colors of a terminal emulator are defined by the terminal emulator, the specific distribution or flavor of insert OS and by the user, in that order. The only somewhat safe assumption here is that the bottom 8 colors will exist and be different enough to allow us to pretend we're dealing with the standard set of colors. Colors 8 to 15 can't be assumed to exist at all in case they're the same or only slightly different, and their behavior can't be predicted due to terminal options such as colors 8-15 potentially being an alias for 0-7bold. Ditch bold characters.

The main issue will be the inevitable overloading of colors within specific contexts. Bake a dark version, a light version. Ship that. It's a fallback, nothing else.

88c

This is a fairly similar situation, but at least we get bold characters back and we can be sure that red will be red and so on. Follow the same principles, with the addition of accent colors for ui elements. It's a fallback, nothing else.

256c and truecolor

Will be bikeshedded to death, and then some more.

The first thing that needs to be settled is whether the truecolor themes should all be restricted to the xterm palette, and if not, whether having different themes for 256c and TC is a possibility or not. Forcing a truecolor theme to fit into the xterm palette sometimes works mostly ok ( my own themes, lifepillar's version of gruvbox ) but there's no negociating with a 256c palette when things go wrong.

romainl commented 4 years ago

@neutaaaaan

My opinion is that the default colorschemes shouldn't break, no matter where you use them. "Shouldn't break" is not the same as "works" or "works perfectly in the most optimal way", though.

Where Vim doesn't break, built-in colorschemes shouldn't break either.

Italics are indeed not universally available. Falling back to "normal" would probably be acceptable but falling back to "reverse", for example, would break the colorscheme. I would like to test that in as many environments as possible before striking italics out.

I agree that colors 0-15 can't be trusted at all. The color names are only indicative of the platform/app defaults, the indices are different on some platforms, the user can set the value of "Cyan" to any color he wants, etc. but Vim will inevitably be used in 8c or 16c environments so colorscheme authors have to make some assumptions, not to guarantee that their colorscheme works, but to guarantee that it doesn't break.

I, too, have written one of the very few (at the time) colorschemes that used the xterm palette for both cterm*g and gui*g. To me, this creative constraint is a strong guarantee that my colorscheme is going to work in a large number of environments with minimal setup, but I know full well that such constraints can be unwelcome. The xterm palette is very limited (no browns to speak of, for example, everything is over-saturated, etc.) so insisting on such constraints may seem counterproductive.

We need to strike a balance between total creative freedom and neurotic backward compatibility.

neutaaaaan commented 4 years ago

@romainl

My opinion is that the default colorschemes shouldn't break, no matter where you use them. "Shouldn't break" is not the same as "works" or "works perfectly in the most optimal way", though.

My own version of "shouldn't break" is "will always meet some specified baseline behaviour no matter what". The only reliable way to do that is to forego features that can't be expected to exist everywhere. To me the only point of shipping, 16c and 88c themes with vim is to soothe the pain of the poor sods working on boxes they cannot update or don't have privileges on : if they could help themselves out of this situation, they would have done so already.

Italic degrading to reverse is a known issue that's predictable, and is what it degrades to on every system I've used or been told about that did not support italicized characters out of the box. Other gotchas such as colors 8-15 being aliases for bold can be safeguarded against. The only reliable fallback on boxes that have completely messed up ANSI colours is a monochrome theme, either set t_Co=0 or something that only uses colors for ui elements.

I don't expect anyone to side with me on the issue of whether it should be comprehensive like bruin is, or stripped down to the bone like my own t_co=0 fallback, but there's a pretty hard set list of features that cannot be expected to work, ever, in that context, and to me that's what the baseline should be.

romainl commented 4 years ago

Color support grading:

Grade 0c 8c 16c 88c 256c True colors
A Y Y Y Y Y Y
B Y Y Y Y Y N
C Y Y Y Y N N
D Y Y Y N N N
E Y Y N N N N
F Y N N N N N

Grade A environments are the easiest to support: just use gui* and call it a day.

Grade B environments are not easy to support because the xterm palette is not expressive enough and programmatic conversion from true colors to xterm is lossy by definition and can't be trusted anyway.

Grade C environments are too few. I'm not sure it should be considered relevant.

Grade D environments are often older versions of A or B environments.

Grade E environments are few but I'd consider the Linux virtual console to be pretty relevant.

Grade F environments, well… are ancient history but supporting them should be possible by default.

lifepillar commented 4 years ago

Grade F environments,

For those, one might define a single dumb color scheme supporting only dumb terminals and require any other color scheme to fall back to it, e.g., by including a snippet like this:

if !exists('&t_Co') || empty(&t_Co) || &t_Co <= 2
  runtime colors/dumb
endif

This would alleviate developers from the burden of supporting a corner case and would guarantee that any color scheme would not break in limited environments. Such dumb color scheme might even be put outside colors and invoked with source, to make it invisible to users.

About italics, the approach used by disco.vim to detect italics has worked well for me, but I don't know how foolproof it is. Anyway, I think that one has to be pragmatic, and be happy with color schemes that “do not break most of the time”. Again, a possible approach is to generalize the above and have one “bulletproof” color scheme (or one for dark and one for light background) to fallback to when certain baseline requirements are not met.

lifepillar commented 4 years ago

Other important guidelines, IMO, are those concerning filetype-specific and plugin-specific highlight groups. Currently, including them in a color scheme leads to buggy behaviour (at least, as perceived by users). On the other hand, users do want per-filetype or per-plugin customizations. Will this be addressed by Vim?

romainl commented 4 years ago
lifepillar commented 4 years ago

&t_ZH returns ^[[7m, here,

What is “here”? Is it a Vim with has('gui_running') set? The following condition has worked in all the environments I have tried so far:

(&t_ZH != '' && &t_ZH != '^[[7m') || has('gui_running') || has('nvim')

I am curious to know where it would fail.

benknoble commented 4 years ago

What bug is being discussed? We do a bit of work to support specialized plugin/filetype distributions highlight groups over in dracula, but two simple options have always existed:

augroup blah
  autocmd!
  autocmd ColorScheme * hi link pluginGroup StandardGroup
  " or whatever
augroup END

I guess my point is maybe the ecosystem has been doing it wrong for a while—and maybe vim should change to support the ecosystem, idk, but personally I don’t think it’s a bug.

EDIT: I will add that if we ever get tree-sitters (maybe via langservers/text-properties or something), then the filetype-specific stuff should melt away for the most part. Even then, I would still like to see a return to standard groups, as it makes a colorschemers job simple: set colors for the standard groups, and move on.

romainl commented 4 years ago

@lifepillar, the main problem with that test is that ^[[7m is not the only possible value for ZH/sitm.

On this Mac with the latest ncurses installed (IIRC same for all the Macs I've had in the last 10 years so versions don't matter), Vim doesn't get an answer for ZH or ZR so it falls back to the values of mr and me, (reverse mode) which don't produce italics at all. On my three Macs, Vim reports ^[[7m despite the right value for &t_ZH being ^[[3m so Vim gets it wrong and that test gets it wrong, too.

FWIW, I just uninstalled my ncurses and the behaviour is exactly the same. Testing ^]]7m is just not a good idea.

That is the kind of discrepancy we have to deal with if we decide to allow italics.

lifepillar commented 4 years ago

@benknoble I am talking about this: https://github.com/vim/vim/issues/4405.

lifepillar commented 4 years ago

@romainl If I understand correctly, the scenario you are describing would give rise to a false negative: in that case, the color scheme could just conservatively disable italics.

What would be problematic is a false positive, i.e., a situation in which the color scheme adds italic to some highlight groups when Vim displays italic, say, as reverse text.

I am not familiar enough with terminal codes to know whether false positives can be reliably detected or not (your comment seems to imply that they cannot). I can only say, anectodically, that since I have implemented the check above in my color schemes, I haven't got any reported issue about italics displayed in reverse mode or otherwise incorrectly.

romainl commented 4 years ago

@lifepillar testing &t_ZH gives both false negatives and false positives. Simply put:

For what it's worth…

Therefore, testing for &t_ZH != '' or for &t_ZH == '^[[7m' is not a bright idea at all.

neutaaaaan commented 4 years ago

My terminal emulator is set to use xterm-256color.

There's a sub-issue here, in that lots of terminal emulators pretend they're xterm, because a terminfo for xterm is virtually guaranteed to exist on every box their users might ssh into.

The problem is that they're not xterm, and this hack only works because of the common baseline vt100+ecma48 they share with xterm. Sneeze too hard and everything goes to hell.

I seem to remember that @romainl uses Terminal or iTerm2 on a mac. I know for a fact that gnome-terminal pretends it's xterm, despite being wildly incompatible with it. So does Alacritty. I suspect most terminal emulators that rely on libvte do the same thing.

We can't expect users to know about that, understand why it's wrong, and care or even be able to fix it.

If vim cannot reliably tell that a feature is available, and we can't trust the terminal emulators themselves, there's only one solution : ditching features that are known to break. In this specific case, italics.

sheerun commented 4 years ago

I think all most terms that support 256 colors have 256 in name, so we can detect it this way.

Given this discussion I certainly would not allow italics

romainl commented 4 years ago

If vim cannot reliably tell that a feature is available, and we can't trust the terminal emulators themselves, there's only one solution : ditching features that are known to break. In this specific case, italics.

Agreed. Italics and broken-by-design tests are somewhat acceptable in third-party colorschemes not part of the distribution (that's the author's business) but too unpredictable to be in built-in colorschemes.

Alternatively: fix capabilities detection in Vim's core.

brammool commented 4 years ago

My terminal emulator is set to use xterm-256color.

There's a sub-issue here, in that lots of terminal emulators pretend they're xterm, because a terminfo for xterm is virtually guaranteed to exist on every box their users might ssh into.

The problem is that they're not xterm, and this hack only works because of the common baseline vt100+ecma48 they share with xterm. Sneeze too hard and everything goes to hell.

I seem to remember that @romainl uses Terminal or iTerm2 on a mac. I know for a fact that gnome-terminal pretends it's a xterm, despite being wildly incompatible with it. So does Alacritty. I suspect most terminal emulators that rely on libvte do the same thing.

We can't expect users to know about that, understand why it's wrong, and care or even be able to fix it.

If vim cannot reliably tell that a feature is available, and we can't trust the terminal emulators themselves, there's only one solution : ditching features that are known to break. In this specific case, italics.

This is indeed a nasty problem, especially for colorschemes. Users expect them to work without tweaking, and still work if they happen to switch to another terminal. Perhaps with some small color changes, but not wil totally wrong colors.

I have moved the recognition of the terminal version response to the handle_version_response() function. And added the term_props[] array to make it easier to set properties based on the detected terminal. That way, provided that the terminal sends a version number that indicates what works and what doesn't, we can tweak this.

One thing that is currently missing, is whether setting 'termguicolors' will work. In other words: does the terminal accept RGB colors. Currently we just try. Can we dig up for which termresponse this feature is working?

I'm going to add a function to retrieve the detected values: terminalprops()

-- [clop clop] ARTHUR: Old woman! DENNIS: Man! ARTHUR: Man, sorry. What knight lives in that castle over there? DENNIS: I'm thirty seven. ARTHUR: What? DENNIS: I'm thirty seven -- I'm not old! The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\ \\ an exciting new programming language -- http://www.Zimbu.org /// \\ help me help AIDS victims -- http://ICCF-Holland.org ///

romainl commented 4 years ago

@brammool AFAIK, the "definitive" resource about true colors is still https://gist.github.com/XVilka/8346728.

Currently reading ncurses's doc about RGB and setaf/setab.

brammool commented 4 years ago

@brammool AFAIK, the "definitive" resource about true colors is still https://gist.github.com/XVilka/8346728.

Currently reading ncurses's doc about RGB and setaf/setab.

Hmm, the trick to set the color and then read it back seems the most reliable. It's similar to what we do for 'ambiwidth' and recently to check if requesting the cursor properties work.

Would need to:

It's going to be a bit much perhaps. We could only check if setting RGB with semicolons work, it appears they work most widely, even though it's not an official standard.

The underline color is clearing the color in xterm. Not sure what other terminals support it or if it's possible to read it back.

-- The question is: What do you do with your life? The wrong answer is: Become the richest guy in the graveyard. (billionaire and Oracle founder Larry Ellison)

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\ \\ an exciting new programming language -- http://www.Zimbu.org /// \\ help me help AIDS victims -- http://ICCF-Holland.org ///

romainl commented 4 years ago

It's going to be a bit much perhaps. We could only check if setting RGB with semicolons work, it appears they work most widely, even though it's not an official standard.

Testing for semicolons first, then colons, seems to make sense. Maybe after testing for $COLORTERM. I don't know which one is the most involved.

romainl commented 4 years ago

Provisional requirements:

Every colorscheme…

A few problems are still pending, though:

In my opinion, a colorscheme that:

is acceptable.

sheerun commented 4 years ago

I'd also vote to not use underline in any form. Current default vim theme does this for highlighting current line. Very annoying. Dimming / highlighting background color looks far better.

romainl commented 4 years ago

I'd also vote to not use underline in any form. Current default vim theme does this for highlighting current line. Very annoying. Dimming / highlighting background color looks far better.

Would this be OK?

sheerun commented 4 years ago

I think so. Typography should be reserved for something like advanced markdown highlighting

neutaaaaan commented 4 years ago

I do agree that bold and underline should only be used when we need to differentiate ui elements, autocompletion choices and so on, not used as part of syntax highlighting per se.
On the other hand, I disagree with changing the background colour as part of syntax highlighting, as I've never seen a dark theme in which it wasn't positively counterproductive, making the wrong things stand out, or making what they're supposed to highlight harder to read.

I'd also like to remind everybody that the 18 themes vim ships with aren't going anywhere, and that we probably don't want to add too many new themes to that list, lest they eventually fall into the same state of disrepair as the old ones.

I'm definitely in favour of only providing one new light colourscheme and one new dark colourschemes for the 8/16/88c versions, all barebones but functional, and then maybe throwing a couple different ones together for 256c and TC. We can't add too much cruft, we can't pull the cruft from existing themes, and we sure don't want people asking on reddit and stackoverflow why the version of popular theme that ships with vim doesn't have italics, or doesn't rewire things around for 3rd party syntax plugins only to be told to install some separate plugin for popular theme.

Speaking of which, we really need to get a definitive list of what can be changed by a theme, and what cannot.
There are elements that Bram doesn't seem to want us to tweak, such as the recent Debug[xxx] elements, but I do rewire them and will keep rewiring them, because they look like absolute crap if I don't.
I'm also on record for not liking how rewired groups "stay empty/point to nothing" when you switch from a slightly customized colourscheme to a bog standard one.

romainl commented 4 years ago

@neutaaaaan…

I'm afraid a hard ban on ctermbg will be more difficult to sell than one on underline. But you have got a point and legibility will certainly be an important criteria when assessing submissions. One thing we can do, is making legibility a requirement, à la WCAG, and making it part of our tests.

About the 18 default colorschemes, they will be overhauled as part of this project so they won't go anywhere. To be honest, I don't expect to find more than a handful candidates.

We can't add too much cruft, we can't pull the cruft from existing themes

We can and we will.

and we sure don't want people asking on reddit and stackoverflow why the version of popular theme that ships with vim doesn't have italics, or doesn't rewire things around for 3rd party syntax plugins

I want to avoid that as much as possible. That's the reason I would prefer to have simple colorschemes that don't require any fiddling. I'm seriously concerned about the eventual impact of this initiative across support channels: I have mild PTSD from the early days of Solarized and I really don't want to reboot that nightmare.

Speaking of which, we really need to get a definitive list of what can be changed by a theme, and what cannot. There are elements that Bram doesn't seem to want us to tweak, such as the recent Debug[xxx] elements, but I do rewire them and will keep rewiring them, because they look like absolute crap if I don't.

I agree and I've voiced my opinion on that matter earlier. A definitive list of do's and don't's will come soon.

As for your last point about links. This is a painful issue that can't be fixed at the colorscheme-level. It must be fixed in Vim.

benknoble commented 4 years ago

@romainl from solarized, what are you thinking about (installation issues, support my fave plugin issues, or something else)? /just wondering

also, happy to help here as I can

neutaaaaan commented 4 years ago

@benknoble Solarized is an incredibly brittle and overengineered mess, "sold" entirely on hype and pseudo-science, that hasn't been updated in a decade. It doesn't support truecolour, it's impossible to port to 256c, and it's single-handedly responsible for several % of vim-related posts online.

lifepillar commented 4 years ago

I maintain a fork of Solarized that supports true colors, but I agree with you: Solarized has no place in Vim core.

romainl commented 4 years ago

@benknoble, basically what @neutaaaaan and @lifepillar said: it is an abomination that shouldn't exist. Note that the colors themselves of the Vim colorscheme are not in question, it's how it is built that is wrong and that has caused so many issues in the past. UUrgl, you triggered my PTSD…

On a more positive note, a solarized-inspired colorscheme with a palette more compatible with 256c would certainly be acceptable as long as it satisfies our (WIP) requirements.

On a more general note, I want the new colorschemes (and the remakes of the old colorschemes) to be functional out-of-the-box in as many environments as possible without exposing options or requiring any action from the user beyond :colorscheme foobar.

lunacookies commented 4 years ago

@romainl

a solarized-inspired colorscheme with a palette more compatible with 256c

I’m not sure how feasible this is, as IMHO much of Solarized’s characteristic ‘look’ comes from the beige/cream coloured background on the light version, and the deep blue used on the dark version. Neither of these colours has a close enough (in my eyes) equivalent in 256c. Maybe it might be a better idea to focus on adapting colourschemes that are ‘friendly’ to 256c, a quality that definitely requires a background very close to grey.

In particular, I can vouch for remaking Jellybeans, as its colours seem to work especially well in 256c. I actually prefer the 256c version over the True Colour one! Sorcerer/Apprentice and Tomorrow Night are also good candidates.

romainl commented 4 years ago

@arzg Solarized is indeed very non-256c-friendly, which has been the cause of much of the nightmare, so I'm not sure either. My comment was meant to convey the idea that choosing colorschemes will not primarily be a matter of taste. Ideally, I would prefer to leave "I like this colorscheme" and "I don't like this colorscheme" outside of the equation.