Skip to content
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

Delimiter matching in vim is hard to read #9

Open
chipbuster opened this issue Jan 22, 2020 · 11 comments
Open

Delimiter matching in vim is hard to read #9

chipbuster opened this issue Jan 22, 2020 · 11 comments

Comments

@chipbuster
Copy link
Contributor

Hi there!

Thanks for the work on this colorscheme!

One thing I've noticed in vim is that, with this colorscheme, the automatic delimiter highlighting gets a little tricky to read. For example, in the following screenshot, my cursor is actually on the last parenthesis of the line: the blue block after empty is just the matching delimiter highlighting.

image

In this example, it's not too bad, but in large codebases where delimiters may be very far up the page, it causes me to lose track of my cursor sometimes.

I looked over the docs, but I couldn't see a mention of this. Have I missed a setting that controls this or do you know if there's a different setting that interferes with coloring? The same screenshot with the Snazzy colorscheme looks like this:

image

In case it matters, my vimrc is here, and the terminal emulator is Konsole.

@Rigellute
Copy link
Owner

Thank for the feedback!

Hmm... I'm not sure how snazzy has configured the cursor color differently from the rigel theme.

In my case, the cursor color is set by my terminal (in this case I'm using kitty which has a rigel theme too).
image

@chipbuster
Copy link
Contributor Author

Just to be clear, that only happens when I'm hovering over matched delimiters. If I'm hovering over regular characters, the cursor looks totally normal.

@Rigellute
Copy link
Owner

Hmm... strange. Looks like this for me.
image

@chipbuster
Copy link
Contributor Author

chipbuster commented Jan 27, 2020

Okay, this is getting a little weird.

I can confirm that this issue doesn't affect kitty for me (regardless of the kitty colorscheme), but it looks different than yours. If I don't focus the vim window, it looks pretty similar to yours:

image

but if I do focus the window, it looks like this:

image

where the cursor isn't matching, but it's also not identical to the background color. (I'm hovering the right brace in both cases)

xterm has similar behavior, but most of my other terminal emulators (Konsole, gnome-terminal, and alacritty) look like my first screenshot (in the OP) when focused. They look fine (a lot like yours) when the window isn't focused though.

Changing the color scheme in Konsole doesn't seem to affect the behavior of the cursor--it's still nearly-invisible.

This is strange.

@Rigellute
Copy link
Owner

After some investigation, it seems vim uses the terminal curosor color. The built in highlighting variables such as Cursor, TermCursor seem to make no difference (at least for non-gui vim).

Turns out it is possible to dynamically change the terminal's cursor colour from within vim. But this only works for some terminals. (Source 1, Source 2).

To fix your issue, you could try the snippet used in "Source 2" above?

Or perhaps you could configure the cursor colour in your Konsole terminal config?

@chipbuster
Copy link
Contributor Author

Tried to do the configuration in my Konsole config. Is this what you meant? It doesn't seem to fix it :(

image

After reading Source 1, I don't think that applies to me right now. My vim appears to be using the gui colors--in fact if I switch to st, which is mentioned in that answer as being part of the problem, my problem goes away (screenshot below, apologies for potato quality)

image

As far as snippet 2 goes, I'm actually using neovim at the moment, and it already has support for this by default (I did confirm that the bug affects both neovim and vim though).


I've managed to semi-fix this issue by replacing a line in rigel.vim, but it looks sorta janky and I don't think it cuts to the real heart of the problem, which appears to be (and forgive me if I'm wrong here) that our systems appear to be coloring the vim block cursor different.

The line I'm changing right now is the MatchParen line, to hi MatchParen guifg=NONE ctermfg=NONE guibg=#00cccc ctermbg=14 gui=NONE cterm=NONE. This kinda-sorta-ish fixes the issue, but it's ugly as sin and ruins the colorscheme for me, so I'd really prefer to figure out what's going on.

@chipbuster
Copy link
Contributor Author

chipbuster commented Jan 30, 2020

I tell a lie, I was looking at the wrong tab of the settings!

image

If I may ask, do you have cursor_text_color set to something non-default other than background in kitty? If so, that seems to be the cause of the discrepancy.

EDIT: Disregard this :(

@chipbuster
Copy link
Contributor Author

I think I understand now.

The issue is that some of my colorschemes don't have default cursor colors and attempt to infer the draw colors from context. Some of them do what kitty does, and use predefined cursor block/text colors (options 1,2 in the linked comment). Others, like Konsole, will attempt to invert the bg/fg colors on the cell the cursor is on, so that the text is drawn in the bg color and the block is drawn with the fg color (option 3 in the linked comment).

image

Since hi MatchParen inverts the normal colorscheme (using #002635 for fg), the match looks fine on the paren that's not being hovered. On the paren that is being hovered, the colors are inverted, and the cursor block is drawn in #002635. Since this is the same color as the rest of the background, the cursor completely disappears.

I can make this behavior disappear in Alacritty by explicitly setting a cursor color. If I do this, the problem is not present:
image

while if I comment out the cursor colors and let Alacritty try to decide the cursor colors, it is there:
image

So this issue seems to be an interaction between how the terminal emulator chooses to render a block cursor, how vim syntax highlighting works, and the color scheme itself. I see a few ways for me to fix this on my end:

  1. Use a terminal emulator that doesn't attempt to invert fg/bg colors to draw the cursor block.
  2. Explicitly set a cursor color in the configuration for the terminal editor, whether that colorscheme is rigel or not.
  3. Continue to custom patch the rigel.vim colorfile.

Do you think there's another way to fix this?

@Rigellute
Copy link
Owner

Great work laying this all out. This is pretty much my conclusion too.

My preferred fix is your option 2: I think the terminal theme config itself should define a color for the cursor.

This is the only way I can figure out how to change color of the cursor. I tried applying your patch for MatchParen, however this didn't fix the issue as far as I could tell (was testing in iTerm2).

The accompnaying rigel Alacritty color scheme defines the cursor color, in case you are interested in using Alacritty.

Would be cool to have a Konsole rigel theme too, will look into this.

@chipbuster
Copy link
Contributor Author

Would be cool to have a Konsole rigel theme too, will look into this.

One thing about Konsole that I discovered while trying to troubleshoot this is that while you can set the cursor color from the GUI settings, you can't seem to set a text color. This means that e.g. if you set a yellow cursor, red text is rendered as red text against a yellow cursor, which is...less than optimal.

I found an issue on solarized-light that seemed to mirror the one I described here. Their solution was to invert the fg/bg colors while changing one of them to have slightly more contrast. I might give it a go later and see if that fixes it as well--I don't know if it'd be possible to do it without ruining the colorscheme too much though.

@Rigellute
Copy link
Owner

Ah okay cool. Well, I appreciate the effort you've put into debugging this! This is tricky one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants