Skip to content

Tree highlight group color used if opening new buffers using vsplit preview with empty buffer #2951

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
maleksware opened this issue Oct 11, 2024 · 7 comments · Fixed by #2952
Labels
bug Something isn't working reproduced Issue confirmed

Comments

@maleksware
Copy link

Description

When the first action upon opening Neovim is opening a file in vsplit preview while there is a default empty buffer and then closing all windows except the nvim-tree one, the colorscheme of subsequently opened windows is corrupted (NvimTreeNormal is applied to them). This is probably closely related to Lualine and its globalstatus configuration parameter.

Neovim version

NVIM v0.10.2
Build type: RelWithDebInfo
LuaJIT 2.1.1725453128

Operating system and version

Linux 6.11.2-arch1-1

Windows variant

No response

nvim-tree version

4a9e82d

Clean room replication

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

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",
      'nvim-lualine/lualine.nvim'
    },
    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()
  local function ot(bufnr)
    local api = require("nvim-tree.api")

    local function opts(desc)
      return { desc = "nvim-tree: " .. desc, buffer = bufnr, noremap = true, silent = true, nowait = true }
    end

    api.config.mappings.default_on_attach(bufnr)

    -- open as vsplit on current node
    local function vsplit_preview()
      local node = api.tree.get_node_under_cursor()

      if node.nodes ~= nil then
        -- expand or collapse folder
        api.node.open.edit()
      else
        -- open file as vsplit
        api.node.open.vertical()
      end
    end
    vim.keymap.set("n", "o", vsplit_preview, opts("vsplit preview"))
  end
  require("nvim-tree").setup {
    on_attach = ot,
  }
  require("lualine").setup {
    options = {
      globalstatus = true,
    }
  }
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

An extra file with dummy contents is needed in the directory with the clean room config (let's call it a.txt).

  1. nvim -nu /tmp/nvt-min.lua
  2. :NvimTreeToggle
  3. o on lazy-lock.json
  4. Navigate back to the tree (C-w h)
  5. o on init.lua, pick window B
  6. Write and close all buffers including the default empty one (:wq or :q)
  7. Open a.txt with either or o from the tree or using :e a.txt
  8. Verify that the buffer inherits the colorscheme of the tree: :hi NvimTreeNormal guibg=#909090

The issue is not reproduceable with Neotree and without globalstatus = true in Lualine (or when Lualine is disabled).
The difference in colors is particularly noticeable when NvimTreeNormal significantly differs from the default window background.

Expected behavior

The highlight group is not applied to buffers opened after such operation.

Actual behavior

The opened buffer fully inherits the background and foreground colors of nvim-tree, signified by the NvimTreeNormal.
image

@maleksware maleksware added the bug Something isn't working label Oct 11, 2024
@alex-courtis
Copy link
Member

Is this the replicator for #245 #245 (comment) ?

@alex-courtis
Copy link
Member

alex-courtis commented Oct 12, 2024

It looks like it's just the window picker being shown that is the issue here.

laststatus 3 is the determining factor, which lualine is setting.

Minimal config, only one file foo in the directory.

nvim -nu /tmp/nvt-min.lua
:set laststatus=3
:vsplit
:NvimTreeOpen
<CR> on foo
<Esc>
close other windows
<CR> on foo

@alex-courtis alex-courtis added the reproduced Issue confirmed label Oct 12, 2024
@maleksware
Copy link
Author

Yes, this replicates the behaviour brought up in the discussion in #245. Thanks for finding a smaller config - one of the weird things was that files that were previously opened before everything was :wq-ed still opened with the uncorrupted colors, which is why I included multiple files in my config

@alex-courtis
Copy link
Member

This is appears to be caused by pick_win_id pushing and popping &winhl in the laststatus == 3 blocks. They operate on non-selectable windows only.

There is no need to push and pop &winhl as it is not mutated. Remove it.

Tangential: using &winhl has been historically problematic and we've moved to vim.api.nvim_set_hl etc. with namespaces. Doesn't affect this however it would be good to do at some stage.

@alex-courtis
Copy link
Member

I'd be most grateful if you thoroughly tested a fix branch @maleksware

It would be great to test whether the lualine flashing etc. are resolved.

cd /path/to/nvim-tree.lua
git pull
git checkout 2951-highlights-incorrect-following-cancelled-pick

When you're finished testing:

git checkout master

@maleksware
Copy link
Author

This seems to have fixed it, yay! Tested with Catppuccin as well, it works. Thanks a lot! Do you want me to follow up in that Lualine issue?

Lualine flicker is still there, though. It seems shorter though, maybe that is just a re-rendering thing. And again, it only occurs when there is an empty buffer present.

@alex-courtis
Copy link
Member

This seems to have fixed it, yay! Tested with Catppuccin as well, it works. Thanks a lot! Do you want me to follow up in that Lualine issue?

Many thanks, yes please!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug Something isn't working reproduced Issue confirmed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants