-
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
Can we fix the default colorscheme ? #250
Comments
Just to be clear, when you say "gruvbox256c", you mean
right? |
For all intents and purposes, yes. |
Some of those issues have, I think, been demonstrably broken for a while. As a matter of fact, I've had various iterations of the following fixes in my portable minimal
I am not sure when, exactly, The relevant section of |
I think we should try to fix it in
@chrisbra what do you think? |
Well, what exactly would you suggest to fix here? I had a similar issues with the Visual highlighting before: vim/vim#8247 But nobody saw this as an actual issue 🤷 |
Make Visual non-transparent with bg and fg setup instead of using |
@chrisbra the direction we took with the remakes and the new colorschemes is to explicitly specify The upside is simply that the visual selection is readable in any context, with or without syntax highlighting. The downside is of course that, the visually selected area loses its syntax highlighting, which some users might find discomforting in some cases. From our point of view, that of people who dread using visual mode in FWIW, here are two screenshots of ![]() ![]()
Changing the style of ![]() ![]() Note that I haven't put a lot of effort into this so some other combination might work better. For reference, here are some of the remakes, some of the new ones, and lastly one of mine, all with readable, working, Delek: ![]() Ron: ![]() Zaibatsu: ![]() Habamax: ![]() Malotru: ![]() |
Okay, I guess I am too used to the current broken highlighting, I actually quite like, that the syntax highlighting is still visible in visual mode, but I can see why this causes problems. I am even used to Vim using light background with a default putty colorscheme (which means it is using black background). So the following patch should remove the
It works okay with a dark and light putty terminal, only in 8 color mode, one cannot see the default background color, since it is black as the Normal one. Not sure if 8 color terminals still matter nowadays. And then I am not good with visualizing, so don't know 🤷 |
Thx, @chrisbra I think it would be easier to create a PR and check results there. We should target all kind of things (no color mode, 8 color mode, etc) |
The default visual highlighting currently is nice in that it overlays the actual syntax highlighting by using a separate distinct background color. However, this can cause hard to read text, because the contrast between the actual syntax element and the background color is way too low. That is an issue, that has been bothering colorschemes authors for quite some time so much, that they are defining the Visual highlighting group to use a separate foreground and background color, so that the syntax highlighting vanishes, but the text remains readable (ref: vim/colorschemes#250) So this is an attempt to perform the same fix for the default Visual highlighting and just use a default foreground and background color instead of using reverse. Current issues: - doesn't work well in 8 color mode, since the background and foreground colors used remain un-distinguishable. I also removed the hard-coded changes to the Visual highlighting in init_highlight. It's not quite clear to me, why those were there and not added directly to the highlighting_init_<dark|light> struct. I hope this makes kind of sense. Signed-off-by: Christian Brabandt <cb@256bit.org>
I'm sorry I haven't been able to contribute much lately, work's been pretty hectic. I think it's fairly obvious from my example screenshots that if I were to fix all versions of the light default colorscheme, I'd basically rebuild them on top of As for 8c terminals, yes, they are relevant. Not only do most people not know anything about terminfo, anytime you use tmux or screen without a config file, they default to the 8c version of their terminfo. This is how most people use multiplexers, and this is not about to change. |
There are 3 intertwined topics here:
If on paper the best course of action would be to tackle those issues in the order above, I'm afraid there is too much interplay between them to be able to do meaningful work on one item without impacting the others. We'd also introduce the possibility of having to reconsider or further tweak breaking changes after they've been pushed to vim proper, which I believe we'd all rather like to avoid. Similarly, this is work that ought to be out by vim 9.1.0, to avoid having to bother distribution maintainers with implementing specific patches manually. I should be able to work on a patch this week, so we can at least get the ball rolling. |
I've been putting some work into this branch This only addresses the issues mentionned in my original post, somewhat less intrusively overall. The dark colorscheme has similar issues that we're also going to have to fix. |
The default visual highlighting currently is nice in that it overlays the actual syntax highlighting by using a separate distinct background color. However, this can cause hard to read text, because the contrast between the actual syntax element and the background color is way too low. That is an issue, that has been bothering colorschemes authors for quite some time so much, that they are defining the Visual highlighting group to use a separate foreground and background color, so that the syntax highlighting vanishes, but the text remains readable (ref: vim/colorschemes#250) So this is an attempt to perform the same fix for the default Visual highlighting and just use a default foreground and background color instead of using reverse. I also removed the hard-coded changes to the Visual highlighting in init_highlight. It's not quite clear to me, why those were there and not added directly to the highlighting_init_<dark|light> struct. Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: UX of visual highlighting can be improved Solution: Improve readibility of visual highlighting, by setting better foreground and background colors The default visual highlighting currently is nice in that it overlays the actual syntax highlighting by using a separate distinct background color. However, this can cause hard to read text, because the contrast between the actual syntax element and the background color is way too low. That is an issue, that has been bothering colorschemes authors for quite some time so much, that they are defining the Visual highlighting group to use a separate foreground and background color, so that the syntax highlighting vanishes, but the text remains readable (ref: vim/colorschemes#250) So this is an attempt to perform the same fix for the default Visual highlighting and just use a default foreground and background color instead of using reverse. I also removed the hard-coded changes to the Visual highlighting in init_highlight. It's not quite clear to me, why those were there and not added directly to the highlighting_init_<dark|light> struct. closes: #13663 related: vim/colorschemes#250 Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: UX of visual highlighting can be improved Solution: Improve readibility of visual highlighting, by setting better foreground and background colors The default visual highlighting currently is nice in that it overlays the actual syntax highlighting by using a separate distinct background color. However, this can cause hard to read text, because the contrast between the actual syntax element and the background color is way too low. That is an issue, that has been bothering colorschemes authors for quite some time so much, that they are defining the Visual highlighting group to use a separate foreground and background color, so that the syntax highlighting vanishes, but the text remains readable (ref: vim/colorschemesvim/vim#250) So this is an attempt to perform the same fix for the default Visual highlighting and just use a default foreground and background color instead of using reverse. I also removed the hard-coded changes to the Visual highlighting in init_highlight. It's not quite clear to me, why those were there and not added directly to the highlighting_init_<dark|light> struct. closes: vim/vim#13663 related: vim/colorschemes#250 vim/vim@e6d8b46 Co-authored-by: Christian Brabandt <cb@256bit.org>
…#27256) Problem: UX of visual highlighting can be improved Solution: Improve readibility of visual highlighting, by setting better foreground and background colors The default visual highlighting currently is nice in that it overlays the actual syntax highlighting by using a separate distinct background color. However, this can cause hard to read text, because the contrast between the actual syntax element and the background color is way too low. That is an issue, that has been bothering colorschemes authors for quite some time so much, that they are defining the Visual highlighting group to use a separate foreground and background color, so that the syntax highlighting vanishes, but the text remains readable (ref: vim/colorschemesvim/vim#250) So this is an attempt to perform the same fix for the default Visual highlighting and just use a default foreground and background color instead of using reverse. I also removed the hard-coded changes to the Visual highlighting in init_highlight. It's not quite clear to me, why those were there and not added directly to the highlighting_init_<dark|light> struct. closes: vim/vim#13663 related: vim/colorschemes#250 vim/vim@e6d8b46 Co-authored-by: Christian Brabandt <cb@256bit.org>
…#27256) Problem: UX of visual highlighting can be improved Solution: Improve readibility of visual highlighting, by setting better foreground and background colors The default visual highlighting currently is nice in that it overlays the actual syntax highlighting by using a separate distinct background color. However, this can cause hard to read text, because the contrast between the actual syntax element and the background color is way too low. That is an issue, that has been bothering colorschemes authors for quite some time so much, that they are defining the Visual highlighting group to use a separate foreground and background color, so that the syntax highlighting vanishes, but the text remains readable (ref: vim/colorschemesvim/vim#250) So this is an attempt to perform the same fix for the default Visual highlighting and just use a default foreground and background color instead of using reverse. I also removed the hard-coded changes to the Visual highlighting in init_highlight. It's not quite clear to me, why those were there and not added directly to the highlighting_init_<dark|light> struct. closes: vim/vim#13663 related: vim/colorschemes#250 vim/vim@e6d8b46 Co-authored-by: Christian Brabandt <cb@256bit.org>
Commit e6d8b4662ddf9356da53f56e363b67b524fd8825¹ of Vim made some changes to how visual highlighting works that interact poorly with our tweaks. Their change, when tweaked by us with `cterm=reverse` resulted in near-invisible highlighting. Ironically, invisible highlighting seems to be one of the problems the Vim developers are trying to avoid with this and other recent related changes. Vim PR #250² has some further commentary relevant to this, including the puzzling statement: We can't rely on fg/bg being different… I do not understand this because, if the foreground and background colours were not different, your text would be invisible. In any useful colour scheme, it seems to me you can rely on the foreground and background colour differing. This commit does something close to reverting to the old behaviour. Visual highlighting flips the foreground and background colours, which leads to something that is both syntax highlighted and readable. Ironically, this is similar to the screenshot of the 8c default highlighting posted in a PR #250 comment³ that user romainl describes as “an abomination.” I guess beauty is in the eye of the beholder. ¹ vim/vim@e6d8b46 ² vim/colorschemes#250 ³ vim/colorschemes#250 (comment)
This post is motivated by this now closed pull request from chrisbra.
I figured that if one of vim's core devs had such different expectations from vim's colorschemes than what they actually are, and have been for 2 decades, issues such as the one highlighted here are likely to have gone unnoticed.
What we currently call "the default colorscheme" is the byproduct of several things :
As I myself get to use "the default colorscheme" pretty much all day long at work, through various environments, versions of vim, and distributions, I've grown to absolutely abhor it.
Not because it's bad per se, but because the user experience is utterly inconsistent.
There's very little that could be done about the 24bit version without effectively breaking it. It's trash, and I don't even care.
The terminal versions, especially the 256c one, could use a lot of tweaking, to fix design decisions that only make sense within the context of the default xterm palette, or to restore functionalities that break over ssh.
The goal of this post is to figure out if a third colorscheme could be implemented within vim as a fallback when it fails to autodetect the background color. This colorscheme would be based upon the light version, which is the actual default colorscheme.
I believe it is viable, because this version of the colorscheme does so many things wrong that they right themselves.
I'll use screenshots from an xterm analogue, quiet (itself essentially a more legible xterm analogue), a gruvbox analogue, and because I think it's fair to acknowledge that there is no silver bullet, a solarized analogue.
All the makeshift modifications displayed in this post will use similar design rules to what I've used in quiet or sorbet :
I use rxvt-unicode and tmux, both configured proprely to use the extended 256c palette.
Here are the aliases used to get vim into the same state it'd be over ssh without a config file:
vim -u NONE +"set nocp" +"syntax on" +"set background=light"
vimdiff -u NONE +"set nocp" +"syntax on" +"set background=light"
Most of the main highlighting palette uses ansi colors, except for spotfixes in places where I believe the default xterm ansi colors really didn't work out, such as the
Statement
group, and diffs.Here's what the light version of default looks like, peering at a spot in a random file that contains a bunch of statements:
xterm256c
quiet256c
gruvbox256c
solarized256c
The fact that bad colors were picked 30 years ago for one terminal emulator's ansi palette shouldn't hinder vim users in 2023.
Remarkably, whoever made this tweak, effectively did what most colorscheme/theme authors seem to do : use orange as a proxy for yellow.
Here's what this looks like with Statement pointing to ansi3:
xterm256c_statement
quiet256c_statement
gruvbox256c_statement
solarized256c_statement
Diffs are plain broken.
They rely on the extended 256c palette but still use the ansi palette for DiffText, which ends up being completely illegible.
They also try to preserve syntax highlighting inside diffed elements, which simply cannot work in this context.
xterm256c_diff
quiet256c_diff
gruvbox256c_diff
solarized256c_diff
There's little point trying to move away from the 256c when it comes to diff. Having its ozn palette is fine, it's the behaviour that's busted and ought to be fixed:
xterm256c_diff_coherent
quiet256c_diff_coherent
gruvbox256c_diff_coherent
solarized256c_diff_coherent
Visual selections are broken. We can't rely on fg/bg being different, or even different enough from ansi7 to be legible.
This happens to me on a daily basis:
xterm256c_visual
quiet256c_visual
gruvbox256c_visual
solarized256c_visual
Fixing this requires bolting selections down to a single color:
xterm256c_visual_coherent
quiet256c_visual_coherent
gruvbox256c_visual_coherent
solarized256c_visual_coherent
Search results are kinda crap for similar reasons:
xterm256c_search
quiet256c_search
gruvbox256c_search
solarized256c_search
And the situation can be remedied somewhat by bolting the color down.
xterm256c_search_coherent
quiet256c_search_coherent
gruvbox256c_search_coherent
solarized256c_search_coherent
This is far from being complete and is just meant to get the ball rolling.
The text was updated successfully, but these errors were encountered: