LSP diagnostics inside nvim-tree may flicker

[des-b]

Description

When diagnostics.enable = true and a filetype-generic LSP (e.g. typos-lsp) is running, one may see flickering of diagnostics in the nvim-tree buffer/window.

On a more complex neovim setup than "Clean room replication" I also observed moderate to high CPU load.

A possible workaround for me was to add a check for vim.bo[bufnr].buflisted in view.lua:491:is_buf_valid. I am new to this stuff and not sure if this would be a valid solution.

Neovim version

NVIM v0.10.2
Build type: RelWithDebInfo
LuaJIT 2.1.1727870382

Operating system and version

Linux 6.11.3

Windows variant

nvim-tree version

master

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",
			-- 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({
		diagnostics = {
			enable = true,
		},
	})
	require("nvim-tree.api").tree.open()
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 = "*",
	callback = function()
                -- please adjust path to `typos-lsp`
		vim.lsp.start({ cmd = { "/home/des-b/.local/share/nvim/mason/bin/typos-lsp" } })
	end,
})

Steps to reproduce

1. Put a file with an invalid name: som.txt
2. Run neovim

Expected behavior

Diagnostic on som.txt shown in nvim-tree should just show ''typos: som should be some"

Actual behavior

The diagnostic is shown but flickers every few ~100ms

[alex-courtis]

I've seen a bit of flickering on and off for the diagnostic status with som, ede and others in files.

With the above setup you'll notice that there are multiple language servers running - it starts a new one whech every file is opened.

Open nvim-tree and two other files:

: ; ps aux | grep typos
alex       13574  0.0  0.0 2323388 21600 ?       Ssl  09:41   0:00 typos-lsp
alex       13609  0.0  0.0 2323380 20756 ?       Ssl  09:41   0:00 typos-lsp
alex       13650  0.0  0.0 2323420 21588 ?       Ssl  09:41   0:00 typos-lsp
alex       13703  0.0  0.0   6396  3840 pts/3    S+   09:42   0:00 grep --color=auto typos
: ;

[alex-courtis]

For other language servers, adding an identifying name is enough to result in the one instance being shared e.g. lua-language-server: wiki: Development: Native neovim Configuration

That doesn't seem to be the case for typos-lsp.

Using the "official" language server manager nvim-lspconfig did work nicely:

local lspconfig = require("lspconfig")
lspconfig.typos_lsp.setup()

You'll need typos-lsp in your $PATH

Please let me know if that works and I'll convert this to a discussion.

[alex-courtis]

• TODO add name to nvt-min.lua as per https://github.com/nvim-tree/nvim-tree.lua/wiki/Development#alternative-setup-native-neovim-configuration

[alex-courtis]

#2956 nvt-min.lua fixed
Updated https://github.com/nvim-tree/nvim-tree.lua/wiki/Development

[des-b]

You are right. With the lspconfig config as you suggested there is no flickering.

I have to check my actual neovim config. (where I already use lspconfig with mason btw. 😅) There I observed the flickering as well. When I find the cause I will post it.

Sorry for the noise and thanks for the rapid response and the effort on nvim-tree!

[alex-courtis]

Sorry for the noise and thanks for the rapid response and the effort on nvim-tree!

No apologies needed; there are some issues here that we need to get to the bottom of.

[des-b]

After a lot of stripping my configuration down I found the cause and the (already existing 🫣) solution. The underlying issue was "fixed" in neovim/nvim-lspconfig@b2c7317. Before this change a FileType autocmd is used to detect if a buffer should be lsp-attached. (normally lspconfig uses BufReadPost)

With the following config I am able to reproduce the issue. Notice I have re-enabled filetypes. (also notice that this still not always causes flickering; see below the example)

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").setup({
    spec = {
    {
       "neovim/nvim-lspconfig"
    },
    {
         "kyazdani42/nvim-tree.lua",
         opts = {
            diagnostics = {
            enable = true,
         },
      },
    },
   },
})

require("lspconfig").typos_lsp.setup({
   cmd = { "PATH-TO-typos-lsp" },
   filetypes = { "*" }, -- or 'NvimTree' if you like
})

vim.keymap.set("n", "<F2>", function()
 require("nvim-tree.api").tree.toggle()
end)

With the configuration above lspconfig attaches the buffer if both criteria are met:

• the filetype matches
• buftype is not nofile (checked in lspconfig/manager.lua:try_add())

Now nvim-tree.lua sets BUFFER_OPTIONS (create_buffer()) in non-deterministic order. I played with this a little bit.

• buftype = "nofile" before filetype = "NvimTree": no flickering
• buftype = "nofile" after filetype = "NvimTree": always flickering

So with the second order the behavior is reproducible since typos-lsp is always attached on nvim-tree.

Flickering itself is caused by lsp diagnostics I guess. When typos-lsp produces diagnostics in nvim-tree for invalid file names this will be detected as a buffer change which in turn will be checked by typos-lsp and this cycles forever.

With this monkey-patched version of nvim-tree's is_buf_valid I can avoid flickering.

local view = require("nvim-tree.view")
local is_buf_valid_orig = view.is_buf_valid
---@diagnostic disable-next-line: duplicate-set-field
view.is_buf_valid = function(bufnr)
 return is_buf_valid_orig(bufnr) and vim.bo[bufnr].buflisted
end

I would like to be able to use typos-lsp on nvim-tree.lua to detect typos in my file names. But I could also see that this would be fragile and might cause trouble in the future. (by setting buftype after filetype in nvim-tree buffer set-up I would be able to)

I am interested in your opinions on how to continue. At least it would make sense to ensure BUFFER_OPTIONS are set in a deterministic order. I could imagine there are other configs/plugins which would be troubled by this non-determinism.

[alex-courtis]

Now nvim-tree.lua sets BUFFER_OPTIONS (create_buffer()) in non-deterministic order. I played with this a little bit.

Wow, great find! We should do this regardless.

Would this deterministic order resolve all the above issues?

An array something like this. Guessed at a sensible order.

---@type { name: string, value: any }[]
local BUFFER_OPTIONS = {
  { name = "buftype",    value = "nofile" },
  { name = "filetype",   value = "NvimTree" },
  { name = "buflisted",  value = false },
  { name = "bufhidden",  value = "wipe" },
  { name = "modifiable", value = false },
  { name = "swapfile",   value = false },
}
---
  bufnr = M.get_bufnr()
  for _, option in ipairs(BUFFER_OPTIONS) do
    vim.api.nvim_set_option_value(option.name, option.value, { buf = bufnr })
  end

[alex-courtis]

With this monkey-patched version of nvim-tree's is_buf_valid I can avoid flickering.

local view = require("nvim-tree.view")
local is_buf_valid_orig = view.is_buf_valid
---@diagnostic disable-next-line: duplicate-set-field
view.is_buf_valid = function(bufnr)
 return is_buf_valid_orig(bufnr) and vim.bo[bufnr].buflisted
end

That is reasonable; we can safely ignore unlisted buffers.

view.is_buf_valid doesn't make much sense: the name is misleading and it's only used in one place. Let's inline it into diagnostics so it is very clear what's happening.

[alex-courtis]

I'd be most grateful for a PR with both these changes; you're the best one to validate the solution ;)