Color schemes after 30ab04e16e1e9e6133590181197b3f8e70cb495e are "broken"

[vp1981]

Steps to reproduce

1. Get recent vim
2. Get latest alacritty
3. Run alacritty with transparent background (I'm using picom)
4. Open a file in vim editor with "pablo" color scheme
5. There background used to be transparent.

Expected behaviour

Before the commit 30ab04e the background for some color scheme (I checked only pablo and ron) was tranparent, because that is how my terminal emulator is configured.

Version of Vim

8.2.4980

Environment

Archlinux x86_64
alacritty 0.10.1 and qterminal 1.1.0
bash: 5.1.16(1)
TERM:
alacritty:

$ env | grep -i term
COLORTERM=truecolor
TERM=alacritty
$ env | grep -i color
COLORTERM=truecolor
GREP_COLORS=mt=01;33
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.swp=00;90:*.tmp=00;90:*.dpkg-dist=00;90:*.dpkg-old=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:

qterminal:

$ env | grep -i term
COLORTERM=truecolor
TERM=xterm-256color
$ env | grep -i color
COLORTERM=truecolor
GREP_COLORS=mt=01;33
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.swp=00;90:*.tmp=00;90:*.dpkg-dist=00;90:*.dpkg-old=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:                                                                                                                                                 
TERM=xterm-256color
COLORFGBG=15;0

Changing TERM in alacritty to xterm-256color doesn't change nothing.

To illustrate the problem, please see the screenshots

alacritty (with tgc off)

alacritty (with tgc on)

qterminal (with tgc off)

qterminal (with tgc on)

Logs and stack traces

No response

[chrisbra]

ping @romainl

[habamax]

With remade colorschemes all of them now have explicitly defined Normal colors.

There might be several solutions to this:

1. do not define normal colors for t_Co=16
2. provide a setting that would prevent defining normal colors
3. explain how change normal colors in user vimrc to have "transparent" background
4. explain where to take legacy colorschemes for those who prefer old ones Keep the originals colorschemes#168

[brammool]

Whether the background should be transparent or not is a user choice. It has a drastic effect, thus we could even duplicate the set of color schemes to make a transparent version of each. So we would have "pablo" and "pablo-transp".
In the implementation the common parts of the colorscheme can be shared. The main disadvantage is making the list twice as long.
An alternative is to use a setting or global variable.

[romainl]

Some of the originals specify a background while some others don't so, if transparency is a user choice, then that choice is expressed by choosing a colorscheme without a background.

FWIW, these are the original cases:

Background defined for GUI and TUI via Normal

• blue
• darkblue
• evening
• industry
• morning
• murphy
• shine

Background defined for GUI only (and "true colors" TUI via termguicolors) via Normal

• delek
• desert
• elflord
• koehler
• pablo
• peachpuff
• ron
• slate
• torte
• zellner

Background not defined via Normal

[none]

My opinion: forcing a background color for TUIs seems to go against the design of some of the original colorschemes so we should change the offending remakes.

We may have to adjust check_colors.vim.

[habamax]

An alternative is to use a setting or global variable.

Another alternative is to use

augroup transparent_bg | au!
    au Colorscheme * hi Normal ctermbg=NONE
augroup END

in user vimrc

[chrisbra]

Yes, I would think this configured by the user by making use of such an autocommand. That's what they are for after all :)

[sthen]

It's not just transparency, I don't use that and many schemes now have a light background instead of dark. Exact behaviour depends on the terminal; for xterm I have a fully coloured light background (so it looks reasonably correct though an unwelcome change to before) or for rxvt-unicode I have a mixture of light background where text is printed (e.g. the message displayed when opening vim with no file) and dark (unprinted lines).

Example before/after with delek in rxvt-unicode:

[habamax]

delek was meant to be a light colorscheme (as well as morning and several others). With current implementation it should look like this:

(The same as GUI version of delek)

Although in your case, it looks wrong indeed.

[vp1981]

@habamax ,
your advice with augroup works fine with following settings in vimrc:

augroup transparent_bg | au!
  au Colorscheme * hi Normal ctermbg=NONE
augroup END
color pablo

Don't know why (I have some sort of color blindness) but I think that colors are changed (I'm using pablo). Is it true or just my perception?

[romainl]

@vp1981 The colors have changed, yes.

We spent months remaking the colorschemes shipped with Vim, which implied, among other things, fixing their color palette so that they offer a more consistent experience across environments. In many cases we had to deal with colorschemes being radically different in color terminals and in GUI. In such cases, we favored the GUI colors because they tended to be the most specific and the most explicit.

In doing so, we knew from the start that some users who would have gotten used to their colorscheme's brokenness over time would be surprised by the changes and, probably, unhappy. But that's how change goes.

If you are not satisfied with the remakes, you can still grab the originals over there and put them in your colors directory.

[vp1981]

@romainl ,
thank you, then it is not my imagination, now the 'pablo' theme in terminal indeed has different colors for "keywords".

If you are not satisfied with the remakes, you can still grab the originals over there and put them in your colors directory.

I appreciate your work, but choosing colors is a pain for me.

Still, do I understand correctly that if I want to play around with colors in terminal (alacritty), say, for the 'pablo' theme, I should look into settings from the line https://github.com/vim/colorschemes/blob/master/colors/pablo.vim#L20
to the line 88?

[chrisbra]

That is understandable and I would say, if you found a reasonably well working (legacy) color scheme that works well enough for you, I would just grab the old version pablo in this case download it into your ~/.vim/colors directory and then you should have that solved already.

Note, I believe creating a good working color scheme for color impacted people (I am also one of those), is also a goal of the colorschemes sub-project, but we are not there yet.

[romainl]

@vp1981 you have quite a few options:

• Override the new version with an autocommand like the one you already have. See this gist for some more on this approach.
• Make your own copy of the new version and adjust it to your liking.
• Use the actual template of the new version, which is a lot more fun than doing it all by hand.
• Grab the original version.

[brammool]

@habamax , your advice with `augroup` works fine with following settings in `vimrc`: ``` augroup transparent_bg | au! au Colorscheme * hi Normal ctermbg=NONE augroup END color pablo ``` Don't know why (I have some sort of color blindness) but I think that colors are changed (I'm using `pablo`). Is it true or just my perception?

The section in the help for colorschemes dives into details too quickly. Let me move the :colorscheme command out of the section about highlighting and add some high level remarks.

…

-- You can tune a file system, but you can't tuna fish -- man tunefs /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[romainl]

@brammool do you mean that you are going to do those changes in the doc or that they should be done?

[brammool]

@brammool do you mean that you are going to do those changes in the doc or that they should be done?

I have made some changes, will send them out soon. Then we can further improve on top of that.

…

-- Marriage isn't a word. It's a sentence. /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[alepinio]

After the update, the default color scheme is different from the color scheme default or it is just me?

At least for me, once the default color scheme is changed, there is no way to get it back unless you run the app again.

UPDATE: for me, legacy color scheme ron looks like new default color scheme.

[romainl]

@alepinio, we didn't touch default or any of the low-level things it relies on. Our work was strictly limited to the other colorschemes distributed with Vim.

As for ron, it was one of the wildest, least consistent, and most broken of the lot. The remake is how ron (and this is true for all of them) should have been made to begin with: with care. To be honest, the original colorschemes were all so sloppily written and broken that they shouldn't have been included in the first place. Including them was a mistake, people got used to the various ways in which they were broken and here we are.

The original ron only defined GUI colors so it looked wildly different in GUI Vim and in TUI Vim, where it depended entirely on the terminal's palette anyway, which means that ron didn't look the same everywhere. Your ron wasn't my ron. The remake is based on the highest def information we could put our hands on: the GUI colors found in the original to guarantee a better consistency. What you get is how ron was meant to look, not how it broke in your particular setup, which, we understand it, might be a radical change.

If you prefer the original ron, feel free to grab it here and put it in ~/.vim/colors/.

[Shane-XB-Qian]

@alepinio recently changes tried to fix termguicolor with transparent issues, and some builtin colo like above said.
but did not change default (vs builtin) colo (wish so!),
and looks did not try to fix termguicolor with transparent in some specific terminal or e.g gnu-screen.
// termguicolor and non-transparent (hi normal ctermbg=234) looks still a bit abnormal in gnu-screen.
// but just a fyi, seems gnu-screen users perhaps more like default colo plus no termguicolor (no good pc screen or at server)

[craigmac]

Please note, if you are using alacritty terminal it identifies itself as 'alacritty' not 'xterm-256color'. I believe there are some hardcoded checks in Vim for an xterm-ish string identifier for $TERM (or maybe it's going straight to terminfo?). One solution you can try @vp1981 is this:

if $TERM ==# 'alacritty'
	let &t_8f = "\<Esc>[38;2;%lu;%lu;%lum"
	let &t_8b = "\<Esc>[48;2;%lu;%lu;%lum"
        set termguicolors
endif

in your vimrc. That's fixed the issue for me. Before that alacritty wouldn't display any colours on vim HEAD builds. Alacritty seems to think it should be fixed on Vim-side. I don't have a dog in the fight, and don't understand enough to help. Neovim has no issues like this, I'm not sure what they did on their end.

[vp1981]

@craigmac, thanks but it doesn't work for me. I have a transparent (opacity: 0.9) background in alacritty and though it is sometimes awkward, I'm used to it. I tried your settings, but I lost the transparency. Besides, new pablo color theme (I tested only it) has very "unpleasant" (for me, please note, I have some kind of color blindness) colors for "Special" and "Identifier" (for example, for ([{}]) and others).

I ended up modifying the new pablo theme a bit (reverting old colors for "Special" and "Identifier") and I'm using it in vim (vim runs in terminal, tmux and ssh).

P.S. I tested your settings in tmux running in alacritty and in just alacritty.

[romainl]

It's worth repeating that the remakes are all based on the highest-definition information available, which is the GUI colors. They are, because of their range, where the author's intent is the most explicit so that's where we got most of our cues. Sadly, colorschemes like the original pablo were not designed carefully or they were but against the author's specific terminal palette, etc. So you get a very precise and specific guifg for Special and a quasi-random ctermfg… and a colorscheme that looks different everywhere and for everyone.

The remakes aim to make all of this more consistent.

[brammool]

@craigmac, thanks but it doesn't work for me. I have a transparent (`opacity: 0.9`) background in alacritty and though it is sometimes awkward, I'm used to it. I tried your settings, but I lost the transparency. Besides, new pablo color theme (I tested only it) has very "unpleasant" (for me, please note, I have some kind of color blindness) colors for "Special" and "Identifier" (for example, for `([{}])` and others). I ended up modifying the new `pablo` theme a bit (reverting old colors for "Special" and "Identifier") and I'm using it in vim (vim runs in terminal, `tmux` and `ssh`).

For now we settled on keeping the opacity and setting the Normal color, since this is needed to make the colorscheme work in most places. In case you prefer a transparent background, you can use an autocommand to set that. There is an example in the help: augroup my_colorschemes au! au ColorScheme pablo hi Normal ctermbg=NONE augroup END With the latest Vim it can be one call (untried): call autocmd_add([#{event: 'ColorScheme', \ group: 'my_colorschemes', \ pattern: 'pablo', \ cmd: 'hi Normal ctermbg=NONE' \ replace: v:true, \ }]) Color blindness I'm afraid is very difficult to tackle. Mainly because every person has a different kind. You can try the available colors schemes to find one that works best, and then use a ColorScheme autocommand to tune it.

…

-- WOMAN: King of the who? ARTHUR: The Britons. WOMAN: Who are the Britons? ARTHUR: Well, we all are. we're all Britons and I am your king. The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[romainl]

Regarding color blindness, there are a couple of colorschemes specifically designed for that and I would like to have one included (not necessarily mine) but…

• they work best in GUI and 256c because they are very picky about colors,
• consequently, they will be broken for anyone not in that context, requiring users to set terminal colors manually.

[chrisbra]

Note: there is also vim/colorschemes#163 which specifically adresses dyslexia, not sure if this is the same as color blindness

[romainl]

@chrisbra no, they are very different, unrelated things.

People affected by some forms of color blindness have troubles discerning two colors with different hues but equal or near-equal brightness because the hue is messed while the brightness is not, so the two colors are both reduced to the same or almost same color. That is why accessibility guidelines generally suggest to avoid using only color to differentiate functionalities and why a colorscheme designed for color blindness must have a high contrast between the colors in the palette).

For people with dyslexia, the stuff I've found online is not super conclusive: some research point to high contrast helping and others point to low contrast being better. From my little understanding, it seems to depend on what people actually do: browsing (high contrast is better) or reading (low contrast is better). A distinction that might be hard to tackle in a Vim colorscheme.

[vp1981]

I think it is worth to mention in documentation about possible ways to get desire result. I have settled on the following

augroup transparent_bg | au!
  au Colorscheme * hi Normal ctermbg=NONE
augroup END
color pablo-t

in .vimrc. The colortheme pablo-t is almost the same as new pablo but with some differences:

$ diff -Naur /usr/share/vim/vim82/colors/pablo.vim ~/.local/share/vim/colors/pablo-t.vim
--- /usr/share/vim/vim82/colors/pablo.vim       2022-05-31 07:44:55.000000000 +0800
+++ ~/.local/share/vim/colors/pablo-t.vim  2022-05-23 13:20:03.589564600 +0800
@@ -1,11 +1,11 @@
-" Name:         pablo
+" Name:         pablo-t
 " Author:       Ron Aaron <ron@ronware.org>
-" Maintainer:   Original maintainerRon Aaron <ron@ronware.org>
+" Maintainer:   Original maintainer Ron Aaron <ron@ronware.org>
 " Website:      https://github.com/vim/colorschemes
 " License:      Same as Vim
-" Last Updated: Wed May 11 22:56:41 2022
+" Last Updated: Wed May 23 08:00:00 2022 UTC

-" Generated by Colortemplate v2.2.0
+" Hand-updated

 set background=dark

@@ -98,10 +98,12 @@
   hi Comment ctermfg=244 ctermbg=NONE cterm=NONE
   hi Constant ctermfg=51 ctermbg=NONE cterm=NONE
   hi Identifier ctermfg=37 ctermbg=NONE cterm=NONE
+  " hi Identifier ctermfg=44 ctermbg=NONE cterm=NONE
   hi Statement ctermfg=142 ctermbg=NONE cterm=NONE
   hi PreProc ctermfg=46 ctermbg=NONE cterm=NONE
   hi Type ctermfg=34 ctermbg=NONE cterm=NONE
-  hi Special ctermfg=21 ctermbg=NONE cterm=NONE
+  " hi Special ctermfg=21 ctermbg=NONE cterm=NONE
+  hi Special ctermfg=63 ctermbg=NONE cterm=NONE
   hi Underlined ctermfg=111 ctermbg=NONE cterm=underline
   hi Ignore ctermfg=16 ctermbg=16 cterm=NONE
   hi Error ctermfg=231 ctermbg=196 cterm=NONE

[romainl]

@vp1981…

I think it is worth to mention in documentation about possible ways to get desire result.

Bram is on it.

Identifier from 37 to 44

That is a sensible change because 44 (#00d7d7) is closer to the intended #00c0c0 than 37 (#00afaf). You should make a PR in vim/colorschemes using the actual template.

Special from 21 to 63

The intended color is #0000ff so 21 is the correct value. While 63 (#5f5fff) is closer to the xterm default I think we should keep the intended color.

--- EDIT ---

In any case, here is a revised snippet for your vimrc that allows you to keep your changes in one place:

augroup my_colors
    autocmd!
    autocmd Colorscheme * highlight Normal ctermbg=NONE
                      \ | higlight Special ctermfg=63
                      \ | highlight Identifier ctermfg=44
augroup END

[brammool]

I think it is worth to mention in documentation about possible ways to get desire result. I have settled on the following ``` augroup transparent_bg | au! au Colorscheme * hi Normal ctermbg=NONE augroup END color pablo-t ``` in `.vimrc`. The colortheme `pablo-t` is almost the same as new `pablo` but with some differences:

You could do this with the original "pablo" scheme and do: augroup transparent_bg | au! au Colorscheme * hi Normal ctermbg=NONE au Colorscheme pablo hi Identifier ctermfg=37 au Colorscheme pablo hi Special ctermfg=63 augroup END color pablo Right?

…

-- ARTHUR: I am your king! WOMAN: Well, I didn't vote for you. ARTHUR: You don't vote for kings. WOMAN: Well, 'ow did you become king then? The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[vp1981]

@brammool , yes, thank you! Brilliant solution, I like it and am using it now.

@romainl , Bram's code makes more sense to me than this

augroup my_colors
    autocmd!
    autocmd Colorscheme * highlight Normal ctermbg=NONE
                      \ | higlight Special ctermfg=63
                      \ | highlight Identifier ctermfg=44
augroup END

because and I don't understand where this my_colors is applied. Nevertheless, I think both do the same thing.

[michael-o]

FWIW: OpenBSD ports now install old color schemes by default since this is too abruptive. I have made the same request for FreeBSD ports as well. I am totally not happy with my beloved slate.

[chrisbra]

Is this just because of the Normal highlighting group? Or what exactly is the problem?

[habamax]

Is this just because of the Normal highlighting group? Or what exactly is the problem?

Many (all?) legacy colorschemes were using first 16 colors no matter if there is 256 color support in the terminal. This is the reason slate was different to almost everyone. Blue statement was a different blue statement depending on the terminal definition of the blue.
And of course the normal group is now also defined, overriding terminal bg.

[habamax]

I believe if @michael-o would put set t_Co=16 into vimrc, it would be almost identical to legacy slate. Plus of course hi Normal ctermbg=NONE in the Colorscheme autocommand.

[michael-o]

This is now it looks for me:

HP-UX with 8.2.5173:
new slate:

legacy slate:

FreeBSD with 9.0.16:
new slate:

legacy slate:

That's just for C. Java source code is worse.

Note: I never figured out why the comments are different between HP-UX and FreeBSD. Both systems are solely accessed by PuTTY on Windows.

[romainl]

Here is a perfect example of the incoherent mess we had to deal with, taken from legacy slate:

:hi Comment term=bold ctermfg=11 guifg=grey40

Of note:

• the author chose to use a "lightyellow" for comments in terminals and a dark grey in GUI,
• comments in your "legacy slate" screenshots are not even the designed "lightyellow" to begin with and, in one of them, you even have an inexplicable red background.

Your "beloved slate" didn't even look the same on two machines accessed from the same terminal emulator. It has always been broken. The new slate at least looks the same everywhere, that's quite the improvement

The design choice in the new slate are dictated by the most hi-def "source of trust" we could find: the GUI colors defined in the original slate itself, which inevitably impacts your terminal experience. That is a trade-off we chose to make in the name of consistency.

Reverting new slate to the hot mess that was legacy slate is, IMO, not going to happen. That's why we preserved the legacy colorschemes.

But there are definitely mistakes in new slate, like PreProc being magenta instead of red. Those need to be fixed. Could you open a separate issue so that we can fix what can be fixed in new slate?

[lifepillar]

@michael-o Are you sure t_Co is 256 in your screenshots? Definitely, comments are yellow in my FreeBSD server if I load the legacy slate:

Both systems are solely accessed by PuTTY on Windows.

This may be the reason.

That said, I agree that the new color schemes are “disruptive”, but in a positive way. I am all for backward compatibility, but insisting on keeping 20th century's broken behavior for the sake of compatibility is silly.

For instance, to test the above, I first loaded legacy slate from my terminal, which has a light background. Of course, the color scheme was unusable, because it was meant to be used with a terminal's dark background. With the new slate, this is a non-issue. And it is just one of the countless improvements people working on the new color schemes have made.

[Shane-XB-Qian]

why not just gave another indicating name? e.g `slate-256` // maybe `silly` but people used to that :-) // though separated to new name, but I guess it is unlike py2 vs py3.

…

-- shane.xb.qian

[lifepillar]

why not just gave another indicating name?

That would have doubled the number of color schemes and might have been confusing for many users.

// maybe silly but people used to that :-)

Maybe the legacy color schemes could be put in pack/dist/opt/legacycolors. You would just need packadd legacycolors then.

[michael-o]

Here is a perfect example of the incoherent mess we had to deal with, taken from legacy slate:

:hi Comment term=bold ctermfg=11 guifg=grey40

Of note:

* the author chose to use a "lightyellow" for comments in terminals and a dark grey in GUI,

* comments in your "legacy slate" screenshots are not even the designed "lightyellow" to begin with and, in one of them, you even have an inexplicable red background.

Your "beloved slate" didn't even look the same on two machines accessed from the same terminal emulator. It has always been broken. The new slate at least looks the same everywhere, that's quite the improvement

The design choice in the new slate are dictated by the most hi-def "source of trust" we could find: the GUI colors defined in the original slate itself, which inevitably impacts your terminal experience. That is a trade-off we chose to make in the name of consistency.

Reverting new slate to the hot mess that was legacy slate is, IMO, not going to happen. That's why we preserved the legacy colorschemes.

But there are definitely mistakes in new slate, like PreProc being magenta instead of red. Those need to be fixed. Could you open a separate issue so that we can fix what can be fixed in new slate?

I totally appreciate your work, do understand the mess and don't expect to revert. I think it was the right think to do, but should have been done in 9 with accompanying text.

[michael-o]

@michael-o Are you sure t_Co is 256 in your screenshots? Definitely, comments are yellow in my FreeBSD server if I load the legacy slate:

Both systems are solely accessed by PuTTY on Windows.

This may be the reason.

That said, I agree that the new color schemes are “disruptive”, but in a positive way. I am all for backward compatibility, but insisting on keeping 20th century's broken behavior for the sake of compatibility is silly.

For instance, to test the above, I first loaded legacy slate from my terminal, which has a light background. Of course, the color scheme was unusable, because it was meant to be used with a terminal's dark background. With the new slate, this is a non-issue. And it is just one of the countless improvements people working on the new color schemes have made.

Well, with PuTTY, both OSes show my t_Co=8. I have then tried from Windows Terminal with PowerShell 7 and OpenSSH 8.9 to connect to both machines. Completely different. FreeBSD is now at t_Co=256 and HP-UX is just black and white because TERM is set to xterm-256color which does not exist on HP-UX. I guess it is a combination of multiple factors which leads to inconsistent behavior even with new color schemes since new slate still looks different depending on terminal and OS.

[neutaaaaan]

I totally appreciate your work, do understand the mess and don't expect to revert. I think it was the right think to do, but should have been done in 9 with accompanying text.

This would arguably have been much worse: few people read the documentation, a lot of people have oddball setups, and we'd have drowned under both justified and unjustified bug reports. Later down the line, some linux distributions might have decided to ship vim9.0 with cherry-picked security fixes but none of the runtime updates that would have fixed issues with the colorschemes.

There's no way to do it that doesn't involve some amount of pain, but updating the runtime so that early adopters could report potential issues and give us the opportunity to fix them before a major release was the right call.

[michael-o]

I totally appreciate your work, do understand the mess and don't expect to revert. I think it was the right think to do, but should have been done in 9 with accompanying text.

This would arguably have been much worse: few people read the documentation, a lot of people have oddball setups, and we'd have drowned under both justified and unjustified bug reports. Later down the line, some linux distributions might have decided to ship vim9.0 with cherry-picked security fixes but none of the runtime updates that would have fixed issues with the colorschemes.

There's no way to do it that doesn't involve some amount of pain, but updating the runtime so that early adopters could report potential issues and give us the opportunity to fix them before a major release was the right call.

Right. Whatever you do you do it wrong.

[habamax]

@michael-o there is some work going on vim/colorschemes#207

I have aligned as much as I could TUI 8/16 colors between legacy and new slate.
For GUI/256 I will wait until there would be a decision that would make it "proof" of next pack of people asking to make it like it was before.

[Zemke]

This made me learn why it’s called peachpuff. Oh dear, the background is peach!
After all one can only commend the fixing of the color schemes. Has definitely ruined peachpuff for me but I knew I was caught in the act of being stubborn when I found the related xkcd.

[chrisbra]

you can install the legacy colorschemes as well: https://github.com/vim/colorschemes/tree/master/legacy_colors