Open jan-warchol opened 4 years ago
I have tried an approach based on what lifepillar did for solarized8 (see https://github.com/lifepillar/vim-solarized8/issues/71 and https://github.com/lifepillar/vim-solarized8/commit/de124fa1ea300b02daa0a17219a77d959b5f25d4) but the results were crazy: most of the colors worked except for bright yellow, which was still using 256-color palette.
See also discussion in #59 starting from this comment.
I think I figured out the bright yellow bit after a lot of struggling and digging while attempting to switch to neovim
from vim
. Namely: neither of them preserve all the builtin color aliases (which selenized currently uses in its highlight definitions) between different t_Co
values. If we look here:
https://github.com/vim/vim/blob/8291e91c6b10e0cdeb2f29c8f1a0aad6d5b5c684/src/highlight.c#L521-L567
We end up with (Bright variations are capitalized):
| 8 | 16 | 88 | 256 | Same
-------------+------------+------------+------------+------------+-----
Black | black 0 | black 0 | black 0 | black 0 | YES
DarkBlue | blue 4 | red 1 | blue 4 | blue 4 | !16
DarkGreen | green 2 | green 2 | green 2 | green 2 | YES
DarkCyan | cyan 6 | yellow 3 | cyan 6 | cyan 6 | !16
-------------+------------+------------+------------+------------+-----
DarkRed | red 1 | blue 4 | red 1 | red 1 | !16
DarkMagenta | magenta 5 | magenta 5 | magenta 5 | magenta 5 | YES
Brown | yellow 3 | cyan 6 | 32 | 130 |
DarkYellow | yellow 3 | cyan 6 | 72 | yellow 3 |
-------------+------------+------------+------------+------------+-----
Gray | white 7 | white 7 | 84 | 248 |
Grey | white 7 | white 7 | 84 | 248 |
LightGray | white 7 | white 7 | white 7 | white 7 | YES
LightGrey | white 7 | white 7 | white 7 | white 7 | YES
-------------+------------+------------+------------+------------+-----
DarkGray | BLACK 8 | BLACK 8 | 82 | 242 |
DarkGrey | BLACK 8 | BLACK 8 | 82 | 242 |
Blue | BLUE 12 | RED 9 | BLUE 12 | BLUE 12 |
LightBlue | BLUE 12 | RED 9 | 43 | 81 |
-------------+------------+------------+------------+------------+-----
Green | GREEN 10 | GREEN 10 | GREEN 10 | GREEN 10 | YES
LightGreen | GREEN 10 | GREEN 10 | 61 | 121 |
Cyan | CYAN 14 | YELLOW 11 | CYAN 14 | CYAN 14 | !16
LightCyan | CYAN 14 | YELLOW 11 | 63 | 159 |
-------------+------------+------------+------------+------------+-----
Red | RED 9 | BLUE 12 | RED 9 | RED 9 | !16
LightRed | RED 9 | BLUE 12 | 74 | 224 |
Magenta | MAGENTA 13 | MAGENTA 13 | MAGENTA 13 | MAGENTA 13 | YES
LightMagenta | MAGENTA 13 | MAGENTA 13 | 75 | 225 |
-------------+------------+------------+------------+------------+-----
Yellow | YELLOW 11 | CYAN 14 | YELLOW 11 | YELLOW 11 | !16
LightYellow | YELLOW 11 | CYAN 14 | 78 | 229 |
White | WHITE 15 | WHITE 15 | WHITE 15 | WHITE 15 | YES
NONE | -1 | -1 | -1 | -1 | YES
-------------+------------+------------+------------+------------+-----
To be perfectly honest I have no idea what's up with 16
compared to the other maps... it appears to have swapped blue/red
and yellow/cyan
??? Is that like a compatibility thing or something? I don't get it.
But anyway, if vim thinks you are running with 256 colors, then LightYellow
is going to map to 229
. This is doubly devious in neovim, where the value of t_Co
isn't available during init as implied in the description of this issue.
So it seems like, if we want consistent behavior with terminal color palette overrides, we should never use any of the Light_
aliases... except LightGray
? So maybe it would be better to just hard-code the integers? I wonder if this is more a bug in vim-colortemplate
than actually selenized itself...
IDK, I've been staring at this for too many hours. Hopefully gonna come back and attempt some sort of PR next week.
This is not directly relevant to the issue; feel free not to read this!
If anyone's curious, I figured out why the 16 color mapping is like that... at various points windows terminals were BGR rather than RGB: https://github.com/microsoft/terminal/issues/571#issuecomment-490494968
So color_numbers_16
contains the weird non-ANSI BGR mapping. Then vim has an if statement to try and detect if the terminal actually is ANSI and uses the color_numbers_8
mapping instead:
https://github.com/vim/vim/blob/f6272551bdae3f265b6948a4155b079c37fe110f/src/highlight.c#L609-L625
Whereas neovim just always forces the ANSI (RGB) mapping: https://github.com/neovim/neovim/blob/08986bb5972d5289b5ae581eee20c56387cf5ddd/src/nvim/highlight_group.c#L860-L861
Selenized theme for vim is meant to be used with exact selenized color palette (this requires either truecolor-enabled terminal or configuring ANSI color palette of one's terminal). 256-color version is only an inferior approximation.
Unfortunately, when a terminal advertises itself as supporting 256 colors (e.g. when
TERM=xterm-256color
), Vim will try to use 256-color selenized. It is possible to work around this by settingt_Co=16
, butSo, the goal is to find a way of making selenized use either true color capabilities of the terminal or ANSI color codes, avoiding 256-color version unless explicitly overridden with some option.