Closed STaRDoGGCHaMP closed 5 years ago
This is likely specific to the terminal emulator you're using (I'm guessing the new W10 terminal since you mentioned W10? or is that just your OS?) since it doesn't happen in other terminals I have access to.
It is probably because of how your terminal handles escape sequences, or because of the escape sequences Vim is sending to your terminal. Gruvbox sets term=underline
for the CursorLine
highlight group, Vim and your terminal should be able to handle the rest.
You may find that putting set t_us=
and set t_ue
in your config works. This will disable underline for all highlight groups by not sending the underline escape sequences. Failing that, try hi Cursorline term=none
. A more drastic workaround is to switch terminals. I recommend Alacritty, it's cross platform and I can test it.
If you want more than a workaround and want to find out why underline isn't working, I will redirect you to either Vim or your terminal emulator's issue tracker for now, whichever seems most appropriate to you.
If you're going to pursue the issue elsewhere, in your minimal config, try replacing colorscheme gruvbox
with hi CursorLine term=underline ctermbg=237 guibg=#3c3836
. These are the highlight group parameters gruvbox is using for the cursorline.
Even if it's not underline, gruvbox does not define any new syntax groups or anything specific to the terminal or windows that should cause this. I really have nothing to suspect from gruvbox itself, so I'm going to close this for now. If you investigate this some more and it does still appear to be gruvbox please reopen. Good luck finding this issue.
Thanks for your answer. Just for the record, I was talking about the classic command prompt terminal cmd.exe
, but the problem also occurs with the new Windows terminal. Also, set t_us=
, set t_ue=
and hi Cursorline term=None
did not work. I tried replacing the colorscheme gruvbox
like you suggested and the problem does not occur. See:
There is probably something else going on in gruvbox that causes these issues, but I'm too lazy to dig deeper given that I'm not that familiar with vim internals and terminal emulation. I use gvim 99% of the time so I can live with that shortcoming.
For posterity's sake, adding cterm=none
might do it.
For posterity's sake, cterm=none
does not do it. After some quick mindless bisecting I found that uncommenting the following line solves the problem.
"Solving" as in it does not destroy the syntax highlighting but clears the Normal
highlight group, which is of course not a viable solution. I think this is just a windows cmd idiosynracy. Whatever ¯\_(ツ)_/¯.
As a little bonus to demonstrate the windows cmd
terminal emulation insanity: this is what happens if I use hi clear Normal
instead of uncommenting the above line, which I naively thought would be equivalent, but appearently it isn't:
Probably an escape sequence digestion issue as you suggested. But as I said, not worth the trouble.
On Windows 10 1903 using vim with
cursorline
from the command prompt makes the highlighted line lose its syntax highlighting. Here is a comparison between{,g}vim -u minimal.vim minimal.vim
. Note the lack of syntax highlighting on the left.Any chance this can be fixed?