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

Cursorline highlighting destroys syntax highlighting in Windows command prompt #117

Closed
STaRDoGGCHaMP opened this issue Aug 30, 2019 · 4 comments

Comments

@STaRDoGGCHaMP
Copy link

STaRDoGGCHaMP commented Aug 30, 2019

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?

@rbong
Copy link

rbong commented Aug 30, 2019

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.

@rbong rbong closed this as completed Aug 30, 2019
@STaRDoGGCHaMP
Copy link
Author

STaRDoGGCHaMP commented Aug 31, 2019

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.

@rbong
Copy link

rbong commented Aug 31, 2019

For posterity's sake, adding cterm=none might do it.

@STaRDoGGCHaMP
Copy link
Author

STaRDoGGCHaMP commented Aug 31, 2019

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.

call s:HL('Normal', s:gb.fg1, s:gb.bg0)

"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.

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