CursorLine priority issues when 'linking to Normal'

[bluz71]

• nvim 0.3.1
• all terminals and operating systems.

Since I upgraded to Neovim 0.3.1 I notice NERDTree cursorline looks broken with my preferred Vim theme of moonfly.

Some Googling indicates others have the same experience as noted in this Reddit thread and following image.

Notice the CursorLine in the NERDTree window, it does not stretch across the full width of the window, it only highlights the section after the zsh extension.

I get the same result with my theme.

I think this relates to Neovim changes to CursorLine priority; especially if one only sets a ctermbg color without setting a foreground color. Reading through some of the Neovim CursorLine priority discussions it is mentioned that if one sets foreground and background then the priority system will not come it play. That is correct from my quick testing.

However, in my case I do not want to set a foreground color for the CursorLine, I only set a low contrast background color whilst preserving the existing colors of the current line. Setting a CursorLine foreground color results in the loss of coloring for the current selected line (aka it looks ugly with my theme).

How can I bypass Neovim CursorLine priority changes (for 0.3.1 and above) whilst only setting the background color?

Note, Vim 8.1 renders the NERDTree current line correctly via CursorLine if background is the only color set. Same went for Neovim 0.3.0 and earlier.

Thanks.

[justinmk]

With the cursor on the highlight, use zS from https://github.com/tpope/vim-scriptease to see the highlight group in question. Most likely it's setting the background. If it uses ctermbg=NONE that should work.

[bluz71]

Ok, the highlight group in question is NERDTreeFile which links by default to Normal.

But I can't seem to replicate pre 0.3.1 behaviour (or Vim 8.1 behaviour). Which is a full width CursorLine for the current file in NERDTree.

If I set highlight NERDTreeFile cterm=none in the theme it is a no-op that does nothing (it says cleared). I think the highlight engine in Vim considers this a nothing operation and ignores it.

If I set highlight NERDTreeFile ctermbg=some-color then that color will be displayed as the bg for all NERDTree files not just the current cursor line. No, we don't want that.

If I manually set highlight NERDTreeFile cterm=none at the Neovim command-line after everything has been loaded then that works.

Closing this off seems hasty since we have a divergence with Vim 8.X and Neovim 0.3.0 and earlier without an obvious way for users to get back the old visual behaviour.

[justinmk]

If I set highlight NERDTreeFile cterm=none in the theme it is a no-op that does nothing

That's cterm. Also NONE might be case-sensitive. Did you try ctermbg=NONE ?

Closing this off seems hasty since we have a divergence with Vim 8.X and Neovim 0.3.0 and earlier without an obvious way for users to get back the old visual behaviour.

We might be able to special-case "linking to Normal" so that it works like =NONE. Not sure though... @zhou13 thoughts?

[bluz71]

@justinmk,

No, NONE makes no difference, it is case-insensitive (just tested).

We might be able to special-case "linking to Normal" so that it works like =NONE. Not sure though... @zhou13 thoughts?

My opinion, that feels like a special case code spell. I don't like it.

That being said, I have no idea how to get back the old behaviour whilst also keeping CursorLine priority which the Neovim crew implemented to fix a bunch of other issues.

I think my ideal solution, as a Vim theme author, would be the suggestion of:

highlight NERDTreeFile cterm=none

Currently Neovim treats that as a no-op when read in via *.vim files. Ideally it would be an operation similar to how it works when entered in command mode (which does work and solve the issue).

Lastly, I think this issue should be re-opened until we have a solution or workaround. It highlights a legit regression compared to 0.3.0 and Vim 8.x.

Thanks.

[justinmk]

My opinion, that feels like a special case code spell. I don't like it.

Normal highlight group is already special (in Vim and Nvim). My suggestion is just to recognize its specialness in our recently-added priority logic.

Currently Neovim treats highlight NERDTreeFile cterm=none as a no-op when read in via *.vim files. Ideally it would be an operation similar to how it works when entered in command mode (which does work and solve the issue).

I'm not sure why that would be a no-op. More likely it's just an ordering issue: if you do it after the colorscheme was executed, I would guess it works. Try putting it in an event handler:

au ColorScheme * highlight NERDTreeFile cterm=none

[bluz71]

Normal highlight group is already special (in Vim and Nvim). My suggestion is just to recognize its specialness in our recently-added priority logic.

Ok, in that context you suggestion is reasonable. It would be fine by me if it fixes this and has no deleterious side-effects.

More likely it's just an ordering issue: if you do it after the colorscheme was executed, I would guess it works. Try putting it in an event handler

Unfortunately, it does not work. I put your tip at the end of my init.vim, no good. I also put it in an after/plugin script and still no good. Strange, it feels like it should work.

Basically when I look at the value of NERDTreeFile I get NERDTreeFile xxx links to Normal instead of the desired NERDTreeFile xxx cleared.

[justinmk]

Unfortunately, it does not work. I put your tip at the end of my init.vim, no good.

With the autocmd in place, do the steps and then try :mode to force a screen clear.

[bluz71]

With the autocmd in place, do the steps and then try :mode to force a screen clear.

Negative, no change.

[bluz71]

@justinmk,

I am closing this issue, the obvious solution was staring me in the face from the start but I only just figured it out now.

In my moonfly Vim theme, I simply needed to add:

highlight NERDTreeFile ctermfg=251

For some reason I did not think to set a foreground color for NERDTreeFile, instead I kept experimenting with ctermbg and cterm with no success. Setting the foreground color for the appropriate NERDTree highlight group works perfectly.

Note, the vim-one theme has the same breakage as noted in the original post of this request. I suspect quite a few Vim themes are broken. However, the solution is simple as noted just above.

I don't require any changes to Neovim. Thanks for your help, great project and excellent support.

[Leandros]

Solarized is also broken. Contrary to @bluz71, I believe this is a bug in neovim. It used to work in neovim, and still works in vim.

And for everybody finding this via Google, the fix for solarized dark is

highlight NERDTreeFile ctermfg=14

[mk12]

I'm experiencing this bug as well in nvim 0.3.1 with base16-vim. The cursorline sometimes has gaps in it:

In vim 8.1 this doesn't happen; the cursorline background overrides on "Foo" correctly.

I fixed it for now by adding hi Normal ctermbg=NONE, but I don't know if this will get all of them. Presumably there's some reason why base16-vim sometimes leaves the bg undefined for some groups and explicitly sets it to the terminal's background color for others.

[mg979]

I have the same. It didn't happen in nvim 0.3.0.

In my case I see it for vimUserFunc group, that is linked to Normal group. I think it happens for linked groups, that are linked to groups with a defined bg (gui or cterm doesn't matter). If they link to Normal group, this is sure to happen since its bg is surely defined.

Any way to set CursorLine background's priority higher than other groups?

[zhou13]

To summarize this, this bug was due to my previous pull request to low the priority of CursorLine to fix other bugs. Unfortunately, since CursorLine previously had a higher priority in vim, so syntax author often linked a color back to Normal to "reset" the color, and thus they broke after that pull request.

The simple workaround if you are not using bg color is to clear it using hi Normal ctermbg=NONE. A better way to fix this is to add a very special cases to make CursorLine override Normal in neovim. My guess is that this is not easy. I will check if that is feasible when I have time.

Any way to set CursorLine background's priority higher than other groups?

Sorry, no. Vim's highlight priority is coded by thousands of lines of code rather than a number.

[mg979]

The simple workaround if you are not using bg color is to clear it using hi Normal ctermbg=NONE.

This is only for people using a transparent background. I'm not sure most people do. I don't, for one.

If this is going to be permanent, you should at least fix the syntaxes that are bundled with nvim, and that still link stuff to the Normal group. VimL syntax is one of them.

Normal group could be replaced in these syntaxes by a Neutral group, that has the Normal foreground, but NONE as background, and have those groups that were previously linked to Normal, link to Neutral.

[zhou13]

Normal group could be replaced in these syntaxes by a Neutral group, that has the Normal foreground, but NONE as background, and have those groups that were previously linked to Normal, link to Neutral.

That's unlikely to happen due to the complexity of itself and merging updates on vim script.

[mg979]

Then I think that CursorLine background should have an higher priority over groups whose background color is the same as the Normal one, and that would include Normal group itself.

[bluz71]

The Neovim CursorLine priority changes also breaks the IndentLine plugin with the same visual errors as listed in this issue.

I worked around the NERDTree issue myself in my own moonfly theme, but I can't work around the IndentLine issue.

There is a clear difference in behaviour now between Vim and Neovim with respect to CursorLine. Not an absolute deal breaker, but annoying enough that I would strongly encourage the Neovim team to fix.

justinmk said this earlier this thread:

We might be able to special-case "linking to Normal" so that it works like =NONE. Not sure
though... @zhou13 thoughts?

I believe this issue should be re-opened and retitled.

[mg979]

@bluz71 you could reopen it. The problem is about CursorLine priority, but not necessarily because of incompatibility with certain themes: also syntax can bind groups, in my case it is a syntax problem, not a theme one (I get the same with all themes). So just updating themes can't fix the problem.

[bluz71]

@mg979,

I forgot I could re-open :)

[bluz71]

Retitled: CursorLine priority issues when 'linking to Normal'

[viniciusban]

Same problem here.

[blueyed]

Setting a fg works due to compromise added in #8578.
(I've noticed this with #10256 (adding nocombine)).

[zfzackfrost]

I don't know if anyone has thought of this yet, but I did the following in my init.vim, and its appears to solve the issue:

function! s:CustomizeColors()
	if has('guirunning') || has('termguicolors')
		let cursorline_gui=''
		let cursorline_cterm='ctermfg=white'
	else
		let cursorline_gui='guifg=white'
		let cursorline_cterm=''
	endif
	exec 'hi CursorLine ' . cursorline_gui . ' ' . cursorline_cterm 
endfunction

augroup OnColorScheme
	autocmd!
	autocmd ColorScheme,BufEnter,BufWinEnter * call s:CustomizeColors()
augroup END

As a note, I'm running on Windows Subsystem for Linux (WSL). I have not yet tested this on true Linux.

NVIM v0.4.0-1597-g25fff17d1

[asilvadesigns]

@zfzackfrost works for me! thanks!

[doums]

Hi, any news on this issue ?
I'm also an author of a color scheme, darcula. I encounter the exact same problem in Neovim but it works perfectly on Vim8.1. As explained above the problem occur with lot of highlight groups from different file type that are linked to the Normal group, essentially.
After reading the conversation it seems like the Neovim team suggests to override all the hi groups linked to a group which have a bg value (not NONE) to "fix" the problem...
But it is not viable because we have to replace hundreds of groups defined in various syntax files because there is a plethora of them linked to the Normal group for exmaple...
Like many people here I think you should fix this problem of priority on Neovim side.

[bfredl]

After reading the conversation it seems like the Neovim team suggests to override all the hi groups linked to a group which have a bg value (not NONE) to "fix" the problem...
But it is not viable because we have to replace hundreds of groups defined in various syntax files because there is a plethora of them linked to the Normal group for exmaple...

I do not see this claimed anywhere and it will certainly not fix the problem. The only thing that is relevant is if CursorLine has bg or fg defined itself or via a link to Normal (which is still a problem for some, but not as large as you make it to be).

[msm1723]

@zfzackfrost Thanks for solution. However I'd like to have cursorline text to be syntax highlighted not just white. Could this script be modified in such way?

[zfzackfrost]

@zfzackfrost Thanks for solution. However I'd like to have cursorline text to be syntax highlighted not just white. Could this script be modified in such way?

It should not be white. The white color applies to cterm when in gui and gui when in cterm.

[fullstopslash]

@zfzackfrost Thanks for solution. However I'd like to have cursorline text to be syntax highlighted not just white. Could this script be modified in such way?

It should not be white. The white color applies to cterm when in gui and gui when in cterm.

It's totally white for me as well and still doesn't work as expected.

[averms]

It should not be white. The white color applies to cterm when in gui and gui when in cterm.

It's totally white for me as well and still doesn't work as expected.

This might be because @zfzackfrost's solution doesn't correctly check for
termguicolors or running in a GUI. Here is a version that I've tested using
terminal Neovim and Goneovim:

function! s:CustomizeColors()
    if has('gui_running') || &termguicolors || exists('g:gonvim_running')
        hi CursorLine ctermfg=white
    else
        hi CursorLine guifg=white
    endif
endfunction

augroup OnColorScheme
    autocmd!
    autocmd ColorScheme,BufEnter,BufWinEnter * call s:CustomizeColors()
augroup END

This workaround is also included in my fork of base16-vim. However, it is not
ideal. It means that CursorLine has priority over (AFAIK) everything, not just
Normal. This breaks Error highlighting in many base16 themes and I haven't
thought of a fix for that yet.

EDIT: also negatively affects Diff* highlights as @justinmk states in this pull request

[captnjameskirk]

This issue has caused me so much grief. The workaround listed by @a-vrma is the easiest but, as mentioned, has drawbacks. And it doesn't work for CursorColumn at all. AFAIK nothing similar can fix CursorColumn, which exhibits the same behavior even though no one seems to have mentioned it (see screenshot).

The only thing I've found that fixes both CursorLine and CursorColumn is just about the ugliest hack you can imagine: after a colorscheme is loaded, scan every highlight group to find the ones where ctermbg/guibg have the same value as they do in Normal, or where they are set to bg or background, and then clear ctermbg/guibg from all those highlight groups. It works, but it's just so, so nasty to have to resort to something like that.

Unfortunately, it's the only thing that makes CursorLine and CursorColumn actually work as they should - and as they do in vim8.

[DaTa-]

I was trying to install nvim from fresh and stumbled upon similar issue. Most of popular color schemes I tried have highlight artifacts (incorrect background colors with enabled cursorline, incorrect popup colors).
Here are some examples with gruvbox (right side with fix applied):

I asked #neovim:matrix.org for help and clason pointed me to this issue.

So I wrote a hack similar to suggested by @captnjameskirk: it copies over Normal highlight group, but drops any background attributes; then it re-link any groups linked to Normal to that new group. It's not well tested, I don't have much experience with vim/nvim configuration, but it does work for me.

If it could be useful for someone, here it is:
https://gist.github.com/DaTa-/04bf8ece1c2ee1f8cdf1038bd3bf84bf

To activate it, run this lua file after colorscheme. For example, I put the script at ~/.config/nvim/lua/hl_bg_fix.lua and add this line to init.vim after colorscheme setting:

colorscheme gruvbox
runtime lua/hl_bg_fix.lua

[zfzackfrost]

It should not be white. The white color applies to cterm when in gui and gui when in cterm.

It's totally white for me as well and still doesn't work as expected.

This might be because @zfzackfrost's solution doesn't correctly check for termguicolors or running in a GUI. Here is a version that I've tested using terminal Neovim and Goneovim:

function! s:CustomizeColors()
    if has('gui_running') || &termguicolors || exists('g:gonvim_running')
        hi CursorLine ctermfg=white
    else
        hi CursorLine guifg=white
    endif
endfunction

augroup OnColorScheme
    autocmd!
    autocmd ColorScheme,BufEnter,BufWinEnter * call s:CustomizeColors()
augroup END

This workaround is also included in my fork of base16-vim. However, it is not ideal. It means that CursorLine has priority over (AFAIK) everything, not just Normal. This breaks Error highlighting in many base16 themes and I haven't thought of a fix for that yet.

EDIT: also negatively affects Diff* highlights as @justinmk states in this pull request

Thanks for the correction! I am using your version of my workaround in my config!