-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Cursor Color Contrast Logic is Too Sensitive #4564
Comments
I mean #E19B14 will have extremely bad contrast with almost everything else out there, so I'm not sure what to do here since it seems to be doing its job. At least the contrast of that green to your cursor's yellow is extremely low. What exactly do you want to change, just to lower the threshold? The current threshold is a contrast of So I have very little doubt a contrast of 1.3 justifies switching out the colors. Even if we were to reduce it even more we'd have to use at most @kchibisov what do you think? |
Out of interest, what algorithm does Alacritty use to calculate contrast, and how much does it take hue into consideration? I agree that Truthfully, the reason I created this issue is that it's been noticed the cursor is sometimes hard to see when Vim highlights matching parens (#2398), and @kchibisov and I narrowed down the root cause to this contrast logic. Perhaps there's a better way to approach the problem than this. |
Alacritty uses the W3C standard for color contrast: https://www.w3.org/TR/WCAG20/#contrast-ratiodef |
If the contrast is too low, Alacritty will use inversion though. If that doesn't provide sufficient contrast, there's something wrong with your colors. |
@Neightro @chrisduerr I experimented a bit since I think I'm having the same issue (see also my comment here). It seems that whenever you set both Edit: After trying a bit more I can only say that I have no idea what's going on, at least the gruvbox scheme from here does not work: Edit: Changing to these colors seem to work: colors:
primary:
# hard contrast background - '#1d2021'
background: &gruvbox_dark_bg '#282828'
# soft contrast background - '#32302f'
foreground: '#ebdbb2'
bright_foreground: '#fbf1c7'
dim_foreground: '#a89984'
cursor:
text: '#282828'
cursor: '#ebdbb2'
vi_mode_cursor:
text: '#282828'
cursor: '#ebdbb2'
search:
matches:
foreground: '#282828'
background: '#fabd2f'
focused_match:
foreground: '#282828'
background: '#b57614'
bar:
foreground: '#282828'
background: '#ebdbb2'
line_indicator:
foreground: '#282828'
background: '#ebdbb2'
selection:
text: CellForeground
background: '#ebdbb2'
bright:
black: '#928374'
red: '#fb4934'
green: '#b8bb26'
yellow: '#fabd2f'
blue: '#83a598'
magenta: '#d3869b'
cyan: '#8ec07c'
white: '#ebdbb2'
normal:
black: *gruvbox_dark_bg
red: '#cc241d'
green: '#98971a'
yellow: '#d79921'
blue: '#458588'
magenta: '#b16286'
cyan: '#689d6a'
white: '#a89984'
dim:
black: '#32302f'
red: '#9d0006'
green: '#79740e'
yellow: '#b57614'
blue: '#076678'
magenta: '#8f3f71'
cyan: '#427b58'
white: '#928374' |
I am able to replicate this issue with the following snippet: on=$(tput smso)"no color, standout on"`fb=3;r=255;g=85;b=85;printf '\e[0;%s8;2;%s;%s;%sm colored, standout on ' "$fb" "$r" "$g" "$b"`$(tput rmso)$(tput sgr0)
off="no color, standout off"`fb=3;r=255;g=85;b=85;printf '\e[0;%s8;2;%s;%s;%sm colored, standout off ' "$fb" "$r" "$g" "$b"`$(tput sgr0)
echo $off"\n"$on It appears to be a problem when using standout under certain color combinations. This especially becomes an issue when using cursors with style |
The existing cursor inversion logic was causing more problems than it solved, without solving the problem of invisible cursor when inverting a cell with matching foreground and background colors. This patch reworks this logic and only inverts the cursor when the foreground and background colors of the cursor are similar and the cursor colors aren't set to fixed RGB values. Fixes alacritty#4564. Fixes alacritty#5550.
The existing cursor inversion logic was causing more problems than it solved, without solving the problem of invisible cursor when inverting a cell with matching foreground and background colors. This patch reworks this logic and only inverts the cursor when the foreground and background colors of the cursor are similar and the cursor colors aren't set to fixed RGB values. Fixes #4564. Fixes #5550.
I have a color specified for my cursor. When hovering over text that has the 'reverse' style, the cursor switches to be the inverse of the color underneath it. My understanding, as informed by @kchibisov in #2398, is that this is caused by a feature intended to keep the cursor itself from blending in with text that is very similar in color. However, this functionality kicks in in some situations where it likely shouldn't.
My alacritty.yml
alacritty.yml.txt
To Reproduce
I've found two ways of reproducing this. The first is, while running my config and any program that doesn't change the background color, use the mouse to select over the cursor, which should turn black despite not being similar in color to the highlighted text.
Alternatively, should that approach not work for some reason:
vim -u NONE test.c
int test
syn on | hi Type cterm=reverse gui=reverse
int
, which should be highlighted in lime green. The cursor will turn black, and the character underneath green. (Image is not very accurate, but I can't stop the window from unfocusing when taking a screenshot.)Current Behavior
In many cases, the cursor changes color when hovering over text with the reverse style even if the color of the text is not similar to that of the cursor. My cursor is orange (#e19b14), though it will turn black over text that is green or teal, for instance.
This behavior has the side effect of making the cursor hard to see in many cases, such as when hovering over matching delimiters in Vim with 'matchparen'. This doesn't affect every color scheme, though; only ones using the 'reverse' style with a bright enough color.
Expected Behavior
The cursor only changes color when the background is very similar in color to the cursor itself, such as white on very light gray. Ideally this behavior would never happen with Vim's 'matchparen' highlighting or other one-character highlights, though that's likely a different issue.
System
Manjaro and Arch Linux
alacritty 0.6.0 (04cbf76)
X11 (xorg-server 1.20.10-0)
Please let me know if you need any more information, and I will be happy to oblige.
The text was updated successfully, but these errors were encountered: