Closed habamax closed 2 years ago
Just to make it clear, if normal colors would not be defined, colorschemes might have readability issues due to color blending of syntax elements/chrome with the background of terminal.
@neutaaaaan @romainl @chrisbra we need to chose the least wrong fix :)
can't we just document, that if one needs transparency add the following ColorScheme
autocommand that removes the Normal
colors?
can't we just document, that if one needs transparency add the following
ColorScheme
autocommand that removes theNormal
colors?
This is my preferred solution. If @brammool is ok with this...
FWIW, we do something similar in https://github.com/dracula/vim RE: documenting autocommands for customization, and we still get plenty of questions "How do I customize X." If you want to avoid such questions/issues, I might suggest a different approach; on the other hand, if that doesn't bother you, then I think it's a great approach :)
can't we just document, that if one needs transparency add the following
ColorScheme
autocommand that removes theNormal
colors?
This is the least awful solution, but really, if anyone had cared at all during the last 20 years, we wouldn't be having this conversation about preserving utterly broken behaviour that shouldn't have been allowed to exist at all.
Yet, as @benknoble said, the documentation will be relentlessly ignored for years. If the call was mine to make, I'd just bolt everything down. Someone out there is bound to fork the correct versions of the colorschemes and implement transparency properly.
Shipping 90 colorschemes is not an option : vim already has too many of them as it is.
Shipping transparent alternatives:
That's a ridiculous idea. I don't want to do it.
Documenting an autocommand-based workaround:
I'm OK on principle (after all I have written that thing) but I know that it will be ignored and we will have to point at that part of the doc for years.
On the other hand, I have seen that "problem" expressed a lot over the years. People really want to see through Vim so I would be OK with a) shipping non-transparent colorschemes regardless, and b) having a definitive doc section to point at.
Adding an option:
No, thanks.
Pointing people at the original colorschemes so that they can install the piece of broken crap they are so used to:
I'm OK with that. We could even add a link under :help :colorscheme
.
Removing cterm*g
from Normal
in the remakes that were originally transparent:
It's being nice to people who got used to broken things for years but that kind of attitude is also why the terminal emulator/shells "space" is so shitty and complicated. I could be persuaded to go that way by the boss but that's not my favorite idea.
- Removing
cterm*g
fromNormal
in the remakes that were originally transparent: It's being nice to people who got used to broken things for years but that kind of attitude is also why the terminal emulator/shells "space" is so shitty and complicated. I could be persuaded to go that way by the boss but that's not my favorite idea.
I am ok with that, but we all should understand that we will still get "broken" issues for delek, peachpuff, morning and other light colorschemes anyway (provided we will not make them transparent)
And if we remove Normal from gui too (which is also the case as they claim termguicolors
was set) then gvim would be unusable with these colorschemes as it is by default has white bg.
regarding the rxvt-unicode and delek, I have installed it on Fedora36 ran vim -Nu NONE +"colo delek"
and it works as expected for me:
Closing this as there is a way to override colorscheme's Normal
command documented under :h colorscheme
Open here to follow up https://github.com/vim/vim/issues/10449
So far the issue is about transparency and some other things with "light" colorshemes like delek which @sthen experience on rxvt-unicode.
I am not particularly happy with the global variable that should/would control Normal colors so I consider this as a no-go (might be wrong here)
I guess the most viable solution is to NOT define Normal colors for TUI