[Breaking-Change]: re-work the (default) Visual Highlighting #13663

chrisbra · 2023-12-11T17:06:06Z

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.

habamax · 2023-12-11T22:18:16Z

Windows terminal

Light on light

background=light and actual terminal background is light (termguicolors is set):

background=light and actual terminal background is light (termguicolors is NOT set, t_Co=256):

background=light and actual terminal background is light (termguicolors is NOT set, t_Co=16):

background=light and actual terminal background is light (termguicolors is NOT set, t_Co=8):

background=light and actual terminal background is light (termguicolors is NOT set, t_Co=2):

Dark on light

background=dark and actual terminal background is light (termguicolors is set):

background=dark and actual terminal background is light (termguicolors is NOT set, t_Co=256):

background=dark and actual terminal background is light (termguicolors is NOT set, t_Co=16):

background=dark and actual terminal background is light (termguicolors is NOT set, t_Co=8):

background=dark and actual terminal background is light (termguicolors is NOT set, t_Co=2):

habamax · 2023-12-11T22:26:38Z

I would keep GUI Visual as before -- It didn't have the issue we try to fix (left is NEW, right is OLD):

Well, at least default visual with bg=light, with bg=dark and hi normal guibg=black guifg=white it is not that good, although still readable:

chrisbra · 2023-12-12T15:40:31Z

I have no idea, why compilation fails in CI 🤔

Applying ChrisBra's temptative fixes to highlight.c

habamax · 2024-01-22T22:21:42Z

src/highlight.c

-    CENT("Visual term=reverse",
-	 "Visual term=reverse guibg=LightGrey"),
+    CENT("Visual ctermbg=DarkGrey ctermfg=White",
+	 "Visual ctermbg=DarkGrey ctermfg=White guibg=#6b6b6b guifg=LightGrey"),


If we are not to leave GUI visual as it was before,
I would have made foreground white here then:

To reiterate on GUI visual hl, I would leave light bg the same as before (guifg=NONE guibg=LightGrey):

And would made dark bg a bit more visible(guifg=NONE guibg=#444444):

The main problem with default Visual is in terminal worlds where it is mostly unreadable.

habamax · 2024-01-22T22:25:45Z

src/highlight.c

-    CENT("Visual term=reverse",
-	 "Visual term=reverse guibg=DarkGrey"),
+    CENT("Visual ctermbg=235 ctermfg=LightGrey",
+	 "Visual ctermbg=235 ctermfg=LightGrey guifg=LightGrey guibg=#262626"),


Probably a bit lighter guibg (#444444) would be better:

I think ctermbg=235 is too optimistic, I think DarkGray would be a safer bet

with ctermfg=White:

with ctermfg=Black:

@romainl, @neutaaaaan what do you think?

I think your tweaks to the 24bit version are fine. It's a completely different colourscheme anyway.

On the other hand, I disagree with the changes made to the 256c selections , as both versions are inherently 8c colourschemes that haphazardly use colors from the extended palette.
Being the default colourscheme, this is actually a fairly sensible behavior to ensure the best compatibility possible regardless of configuration mishaps, and I've extended that behavior by bolting as many of the hl groups used during common editing down in my back of the napkin patch referenced earlier.

This is what the end user will see first in most cases.
This is what the end user will end up using in most cases.
We cannot ever assume their environment will be set up correctly.
We cannot ever assume vim will be able to autodetect the terminal background color.
The only safe assumption, is that the light version of the colorscheme is going to be loaded, eventually, and rework that as the new background agnostic default.

Grey is hard to get right in 8c and 16c.

Assuming the user's terminal emulator's palette follows the same structure as the default xterm palette, we only have two greys that can be reliably used for background in 16c:

7 is very light at #dfdfdf,

8 is very dark at #6c6c6c.

This limits what can be done for visual selection if we insist on using grey:

0 on 7 works,

7 on 8 works,

15 on 8 works.

In 8c, the only viable grey background is 7, which restricts us to:

0 on 7

My advice would thus be to use ctermbg=grey ctermfg=black for both 8c (because of 8c limitations) and 16c (because of consistency with 8c):

Note that the limited grey palette is quite problematic when it comes to UI. A mostly grey chrome is quite practical because it doesn't distract from the syntax highlighting. The problem is that we have lots of greys to play with in GUI and 256c but very few in 16c and 8c. If we shoot for consistency, we should, IMO keep all the greys we can for the chrome (status line, tab line, completion menu, etc.). This means using colors as much as possible for in-buffer highlighting.

Something like the following might be more effective?

Grey is hard to get right in 8c and 16c.
Which is why I don't use it.

The only available colors that in the default colourschemes don't outright disappear inside diffs would be green and yellow.
I settled on black foreground, yellow background long ago.

Please take a look at this branch

I'll revert the gui changes, even so I think it doesn't work very well with 'termguicolors' set in dark mode:

I'll also make the suggested changes to use ctermbg=grey ctermfg=black then.

habamax · 2024-01-23T21:40:20Z

src/highlight.c

-    CENT("Visual term=reverse",
-	 "Visual term=reverse guibg=DarkGrey"),
+    CENT("Visual ctermbg=Grey ctermfg=Black",
+	 "Visual ctermbg=Grey ctermfg=Black guibg=DarkGrey"),


As you mentioned earlier, in bg=dark, gui visual looks not that great, we can make it grey34:

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>

chrisbra · 2024-01-25T22:26:20Z

okay, I think I have addressed all concerns and I mark it as ready.

habamax · 2024-01-26T03:08:25Z

Looks good!

Now we need to tackle other things (diff colors and others)

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/colorschemesvim/vim#250 vim/vim@e6d8b46 Co-authored-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>

habamax · 2024-01-29T23:30:36Z

src/highlight.c

    {
-	do_highlight((char_u *)"Visual cterm=reverse ctermbg=NONE",


We might need this for terminals without (or less than 8) color support.

yeah, seems so

There is a breaking change upstream: vim/vim#13663

Cf. vim/vim#13663

lilydjwg · 2024-01-31T04:48:20Z

This is indeed a breaking change. Fortunately the fix was simple (and I don't have a lot of colorschemes).

…#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>

Essentially it undoes the following change in Vim: <vim/vim#13663>

chrisbra mentioned this pull request Dec 11, 2023

Can we fix the default colorscheme ? vim/colorschemes#250

Open

neutaaaaan added a commit to neutaaaaan/vim that referenced this pull request Dec 26, 2023

Apply vim/vim PR vim#13663

81d5848

Applying ChrisBra's temptative fixes to highlight.c

habamax reviewed Jan 22, 2024

View reviewed changes

habamax reviewed Jan 23, 2024

View reviewed changes

chrisbra force-pushed the visual-hl branch from a75adf8 to c0b1bb0 Compare January 25, 2024 22:25

chrisbra marked this pull request as ready for review January 25, 2024 22:25

Adjust screendump tests for new visual highlighting

55654b4

chrisbra closed this in e6d8b46 Jan 28, 2024

echasnovski mentioned this pull request Jan 29, 2024

vim-patch:9.1.0061: UX of visual highlighting can be improved neovim/neovim#27256

Merged

habamax reviewed Jan 29, 2024

View reviewed changes

habamax mentioned this pull request Jan 30, 2024

Update terminal Visual #13940

Closed

lilydjwg added a commit to lilydjwg/dotvim that referenced this pull request Jan 31, 2024

colorschemes: fix Visual highlight with terminal colors

5dd927f

There is a breaking change upstream: vim/vim#13663

lilydjwg added a commit to lilydjwg/dotvim that referenced this pull request Jan 31, 2024

also fix lilydjwg_dark colorscheme

2b682ac

Cf. vim/vim#13663

dmitrivereshchagin added a commit to dmitrivereshchagin/skel that referenced this pull request Apr 10, 2024

Return old highlighting for Visual mode selection

4659dec

Essentially it undoes the following change in Vim: <vim/vim#13663>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Breaking-Change]: re-work the (default) Visual Highlighting #13663

[Breaking-Change]: re-work the (default) Visual Highlighting #13663

chrisbra commented Dec 11, 2023

habamax commented Dec 11, 2023

habamax commented Dec 11, 2023

chrisbra commented Dec 12, 2023

habamax Jan 22, 2024

habamax Jan 22, 2024

habamax Jan 22, 2024

habamax Jan 22, 2024

neutaaaaan Jan 23, 2024

romainl Jan 23, 2024

neutaaaaan Jan 23, 2024

chrisbra Jan 23, 2024

habamax Jan 23, 2024 •

edited

Loading

chrisbra commented Jan 25, 2024

habamax commented Jan 26, 2024

habamax Jan 29, 2024

chrisbra Jan 30, 2024

lilydjwg commented Jan 31, 2024

		{
		do_highlight((char_u *)"Visual cterm=reverse ctermbg=NONE",

[Breaking-Change]: re-work the (default) Visual Highlighting #13663

[Breaking-Change]: re-work the (default) Visual Highlighting #13663

Conversation

chrisbra commented Dec 11, 2023

habamax commented Dec 11, 2023

Windows terminal

Light on light

Dark on light

habamax commented Dec 11, 2023

chrisbra commented Dec 12, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

habamax Jan 23, 2024 • edited Loading

Choose a reason for hiding this comment

chrisbra commented Jan 25, 2024

habamax commented Jan 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lilydjwg commented Jan 31, 2024

habamax Jan 23, 2024 •

edited

Loading