neovim 0.10: window picker changes WinBar highlight

[geril2207]

neovim 0.10: window picker changes WinBar highlight

[alex-courtis]

Yeah, I think it's a good idea. The only thing here is that people may open a bunch of issues(even with mention in doc) about this behavior when facing it.

Indeed. I might just change the title and pin this issue :)

[geril2207]

Yeah, looks like. But most of the themes already have fixed previous highlight groups, so I hope we can close this 😄.

[alex-courtis]

That is unfortunate, it's quite a change. We can fix this.

I'm not quite sure what I'm supposed to see - which element is the incorrect highlight group in that screenshot?

I did try the following with nvim 0.9 and latest nvim-tree, however was unable to see any differences:

:hi WinBar guifg=red guibg=blue
:hi WinBarNC guifg=yellow guibg=green

:hi clear WinBar
:hi link WinBar StatusLine
:hi link WinBarNC StatusLineNC

[geril2207]

To see this one, you should use the nightly build, new colorscheme will be provided in version 0.10 (I guess). Therefore, there is no need to change anything(btw should we?) for version 0.9. However, in version 0.10, the current solution of window_picker uses the StatusLine highlight, which in 0.10 also applies to WinBar. You can see in my first screenshot that the top bar where I have the title (winbar) also has a blue background because of the StatusLine highlight, which applies to WinBar. Of course, I can manually fix this in the config by unlinking the WinBar highlight, but should I?

[geril2207]

About solution, user may have overrided WinBar highlight, so if we could do smth, I think we should save prev highlight WinBar and etc, make window picker and then return back highlight groups. Or maybe should ask neovim(or open an issue) how to make highlight only for StatusLine without any workarounds.

[alex-courtis]

About solution, user may have overrided WinBar highlight, so if we could do smth, I think we should save prev highlight WinBar and etc, make window picker and then return back highlight groups.

We've done something like this in the past.

[alex-courtis]

To see this one, you should use the nightly build, new colorscheme will be provided in version 0.10 (I guess). Therefore, there is no need to change anything(btw should we?) for version 0.9. However, in version 0.10, the current solution of window_picker uses the StatusLine highlight, which in 0.10 also applies to WinBar. You can see in my first screenshot that the top bar where I have the title (winbar) also has a blue background because of the StatusLine highlight, which applies to WinBar. Of course, I can manually fix this in the config by unlinking the WinBar highlight, but should I?

I'm still not sure where the problem is - can you point to the incorrect highlight on the screenshot?

[geril2207]

I'm still not sure where the problem is - can you point to the incorrect highlight on the screenshot?

Nightly:

0.9.4:

[alex-courtis]

Ah I see now, I was not looking in the right place.

In the (soaking) highlight overhaul NvimTreeWindowPicker is now one of the two hardcoded highlight groups:

nvim-tree.lua/lua/nvim-tree/colors.lua

Line 7 in 62eed77

NvimTreeWindowPicker = "guifg=#ededed guibg=#4493c8 gui=bold ctermfg=White ctermbg=Cyan",

I'm out of time... how about:

• repeat the test again on that branch; a lot has changed
• if we need to, make a PR to that branch - it does break a little, so we can break a little more

[geril2207]

Checked hl-overhaul branch, behaves the same. I opened issue in neovim for question about that, maybe we get something what we should do in this case. I think it can be handled by user, if he'd like to remove this, he can manually set hl group or his colorscheme will do it for him.

[gegoune]

Instead of manipulating highlight groups, would using extmarks be an option?

[geril2207]

Instead of manipulating highlight groups, would using extmarks be an option?

Rewrite to extmarks from scratch? I think this could be fixed by colorscheme in future or by user(requires 1/2 lines) without changing smth there. Actually I still have an issue with WinBarNC group which isn't handled by my theme catppuccin, so in my case both(including current one) can be fixed by catppuccin I guess, maybe in other colorschemes can do the same?

[geril2207]

Although, linking WinBarNC and StatusLineNC makes sense, and if it would stay as is, we should make some changes, and rewrite also can be on option. But i dont understand how do you want to do this. Window picker inserts into statusline string, is it possible with extmarks?

[alex-courtis]

Actually I still have an issue with WinBarNC group which isn't handled by my theme catppuccin, so in my case both(including current one) can be fixed by catppuccin I guess, maybe in other colorschemes can do the same?

https://github.com/echasnovski/mini.base16 has nvim-tree specific colours and I've tweaked that before, however there are a lot of themes out there ;)

[alex-courtis]

I've had a play with nvim master and I'm seeing a lot of colour/scheme changes, some of which are quite breaking.

Options:

1. nvim "fixes" it
2. store and reset WinBar HL groups
3. roll with it and embrace winbar, using it as we do statusline

1 is out of our control
2 may not behave well, especially when it has been customised by the user
3 UX may be improved, as it will be easier to "find" the picker character

3 something like:

  -- Setup UI
  for _, id in ipairs(selectable) do
    local char = M.window_picker.chars:sub(i, i)
    local ok_status, statusline = pcall(vim.api.nvim_win_get_option, id, "statusline")
    local ok_winbar, winbar = pcall(vim.api.nvim_win_get_option, id, "winbar")
    local ok_hl, winhl = pcall(vim.api.nvim_win_get_option, id, "winhl")

    win_opts[id] = {
      statusline = ok_status and statusline or "",
      winhl = ok_hl and winhl or "",
      winbar = ok_winbar and winbar or "",
    }
    win_map[char] = id

    vim.api.nvim_win_set_option(id, "statusline", "%=" .. char .. "%=")
    vim.api.nvim_win_set_option(id, "winbar", "%=" .. char .. "%=")
    vim.api.nvim_win_set_option(id, "winhl", "StatusLine:NvimTreeWindowPicker,StatusLineNC:NvimTreeWindowPicker,WinBar:NvimTreeWindowPicker,WinBarNC:NvimTreeWindowPicker")

Above could be tweaked to test for local or global winbar and only use if present.

[geril2207]

1. I dont think nvim would change that, this link to statusline hl groups actually makes sense for default colorscheme.
2. Looks like overhead, but we can achieve the same behaviour as previous.
3. Looks nice, but wondering about if someone don't like, can he disable it, if we do this feature as a workaround.

How popular is winbar? What if we leave a comment somewhere in the documentation, for example, in troubleshooting, that you can manually set WinBarNC. Perhaps in the future, color schemes will handle the WinBarNC (requires one line from the user) group, and we won't need to do anything. Additionally, we can implement a third option, but make it configurable.
By the way, even if we fix it, I still need to override the WinBarNC(until my theme does it).

UPD: catppuccin/nvim#626 fixed for me 😄

[alex-courtis]

By the way, even if we fix it, I still need to override the WinBarNC(until my theme does it).

I think you're right - do nothing and just document it.

Colour schemes catppuccin and mini base 16 already explicitly set WinBar and I imagine that most power users have a third party colour scheme.

Proposal: wait until 0.10 is released, as things may change, then document the NvimTreeWindowPicker behaviour w.r.t. WinBar and StatusLine.

[geril2207]

Proposal: wait until 0.10 is released, as things may change, then document the NvimTreeWindowPicker behaviour w.r.t. WinBar and StatusLine.

Yeah, I think it's a good idea. The only thing here is that people may open a bunch of issues(even with mention in doc) about this behavior when facing it.

[alex-courtis]

@geril2207 it looks like they've "fixed" it here: neovim/neovim@0c850ad

That default link is gone and WinBar* have their own specific highlights. I'd be most grateful if you could test...