after #2415 NonText and WinSeparator have no highlight

[litoj]

Description

you can also see the weird ^^^^ in my statusline that appear only whenever I enter the NvimTree window (I have laststatus=3)

Neovim version

NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1702233742

Operating system and version

Linux IP5Pro 6.7.0-arch3-1 #1 SMP PREEMPT_DYNAMIC Sat, 13 Jan 2024 14:37:14 +0000 x86_64 GNU/Linux

Windows variant

No response

nvim-tree version

e9c5abe

Clean room replication

vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1

vim.cmd 'hi link WinSeparator LineNr'

vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvt-min/site]]
local package_root = "/tmp/nvt-min/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
  require("packer").startup {
    {
      "wbthomason/packer.nvim",
      "nvim-tree/nvim-tree.lua",
      "nvim-tree/nvim-web-devicons",
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. "/plugin/packer_compiled.lua",
      display = { non_interactive = true },
    },
  }
end
if vim.fn.isdirectory(install_path) == 0 then
  print "Installing nvim-tree and dependencies."
  vim.fn.system { "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path }
end
load_plugins()
require("packer").sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua setup()]]
vim.opt.termguicolors = true
vim.opt.cursorline = true

-- MODIFY NVIM-TREE SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
_G.setup = function()
  require("nvim-tree").setup {}
end

-- UNCOMMENT this block for diagnostics issues, substituting pattern and cmd as appropriate.
-- Requires diagnostics.enable = true in setup.
--[[
vim.api.nvim_create_autocmd("FileType", {
  pattern = "lua",
  callback = function()
    vim.lsp.start { cmd = { "lua-language-server" } }
  end,
})
]]

Steps to reproduce

open with the provided minimal config (or any config really) and :NvimTreeOpen and :vsplit.

Expected behavior

WinSeparator and NonText highlights are consistent across windows

Actual behavior

they are not highlighted at all

[alex-courtis]

I can see the WinSeparator issue; it appears to be similar to #2652

Options:

1. Don't link when it would be "circular" i.e. default WinSeparator->NvimTreeWinSeparator->WinSeparator
2. Don't link at all; set the window namespace highlights to the actual values

1,2 would require the namespace highlights to be rebuilt on window create. User changes e.g. :hi NvimTreeWinSeparator guifg=magenta would require the window to be reopened to take effect.

[alex-courtis]

I've seen the ^^^^ business before when messing with window picker status bar NCs. Changing the entire status line is odd.

@JosefLitos I afraid I'm not sure what I'm looking at with the NonText; the ~ end of buffer characters are rendered as normal. Can you give me some directions as to how to reproduce?

[litoj]

The issue with NonText is no highlight, as with WinSeparator - probably even the same reason.

At least that's what I observe using any config (default/minimal included).

I've seen the ^^^^ business before when messing with window picker status bar NCs. Changing the entire status line is odd.

I must point out that that happens only when using a statusline plugin (feline and lualine both behaved the same). It also changes just the statusline belonging to the NvimTree window (I am using laststatus=3 in the screenshot of my config).

[alex-courtis]

Ah thank you, I did not see the different colour in the tree window.

It looks like all the tree window (namespaced) highlights are misbehaving. #2652

It might be necessary to revert from the new highlight namespace mechanism to the deprecated winhl.

[alex-courtis]

Minimal reproduction case:

vim.opt.termguicolors = true
vim.opt.number = true
vim.opt.relativenumber = true

NS_ID = vim.api.nvim_create_namespace("nvim_tree")

vim.cmd([[
":hi WinSeparator guifg=green
:hi VertSplit guifg=yellow

:hi link NvimTreeLineNrAbove LineNrAbove

:hi link NvimTreeWinSeparator WinSeparator
]])

local function apply_winhl_above()
  vim.api.nvim_set_hl(NS_ID, "LineNrAbove", { link = "NvimTreeLineNrAbove" })
  vim.api.nvim_win_set_hl_ns(0, NS_ID)
end

local function apply_winhl_sep()
  vim.api.nvim_set_hl(NS_ID, "WinSeparator", { link = "NvimTreeWinSeparator" })
  vim.api.nvim_win_set_hl_ns(0, NS_ID)
end

vim.keymap.set("n", ";", ":", { noremap = true })
vim.keymap.set("n", "<space>a", apply_winhl_above, { noremap = true })
vim.keymap.set("n", "<space>s", apply_winhl_sep, { noremap = true })

apply_winhl_above clears LineNrAbove as it is a circular link chain: LineNrAbove->NvimTreeLineNrAbove->LineNrAbove->LineNr

apply_winhl_sep clears the separator in a somewhat similarl manner: WinSeparator->NvimTreeWinSeparator->WinSeparator->VertSplit

We were using &winhl successfully. The recommended replacement nvim_set_hl and nvim_win_set_hl_ns should behave similarly, however this note seems to be the key difference:

    Note:
        Unlike the `:highlight` command which can update a highlight group,
        this function completely replaces the definition. For example:
        `nvim_set_hl(0, 'Visual', {})` will clear the highlight group
        'Visual'.

What is the behaviour when you have circular link chains?

[alex-courtis]

Further experimentation with highlights in a namespace has not been successful:

Avoiding links (1) works, however does not allow a user to add / remove NvimTree links or definitions. This is a problem as users can and will define highlights after first load. Stale links may not be deleted from the namespace, only cleared. Relinking from the namespace to the global via id (minimal API support and undocumented feature of nvim_set_hl) results in odd behaviour with highlights changing as window focus changes.

Further workarounds such as recreating the namespace whenever the window is created are not desirable as namespaces cannot be deleted.

Looking at neovim master it seems that the highlighting API is still a work in progress.

⁂ moving back to &winhl is the way forward. Combined highlights will pollute the global namespace, however they are combinations rather than permutations as the order is fixed.