BUG: Neo-tree window "jumps" when opening files

[georgeguimaraes]

Did you check docs and existing issues?

• I have read all the docs.
• I have searched the existing issues.
• I have searched the existing discussions.

Neovim Version (nvim -v)

NVIM v0.10.0-dev-628+g3ecd45ded-Homebrew

Operating System / Version

MacOS 14.0

Describe the Bug

When browsing a code base with lots of directories opened (to fill up the neo-tree window and be able to scroll it), when I open a file that I have to scroll down to get to, the neo-tree window will jump to the top (see the video below).

I've tracked the issue to document_symbols. When I don't have it enabled, no jumping occurs. The config below reproduces this problem.

Screenshots, Traceback

CleanShot.2023-07-04.at.11.41.37-converted.mp4

Steps to Reproduce

1. Open project
2. Expand a bunch of directories to fill up the screen
3. Open files that are close to the bottom of the neo-tree window

Expected Behavior

The neo-tree window should not jump around when opening files. I managed to fix it by not enabling document_symbols. (I'm using LazyVim, and LazyVim enabled document_symbols).

Your Configuration

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
	vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
	vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
	"folke/tokyonight.nvim",
}

local neotree_config = {
	"nvim-neo-tree/neo-tree.nvim",
	dependencies = { "MunifTanjim/nui.nvim", "nvim-tree/nvim-web-devicons", "nvim-lua/plenary.nvim" },
	cmd = { "Neotree" },
	keys = {
		{ "<Leader>e", "<Cmd>Neotree<CR>" }, -- change or remove this line if relevant.
	},
	opts = {
		sources = { "filesystem", "buffers", "git_status", "document_symbols" },
	},
}

table.insert(plugins, neotree_config)
require("lazy").setup(plugins, {
	root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")

[pysan3]

This should be a duplicate of #996.

Am I right? @georgeguimaraes

[georgeguimaraes]

@pysan3 Could be. Feel free to close it, of course.

I tried to trigger this behaviour with my left-side Neovim tree in qmk_firmware by opening and closing directories, but the window didn't jump.

However, when I opened files, it did trigger the same behaviour as my issue here.

That is fixed if I remove "document_symbols" from the sources.

[pysan3]

That is fixed if I remove "document_symbols" from the sources.

Hmm, this is weird. It might be caused by a different thing.

I'll leave this opened and will look into this this weekend if possible.

Thank you very much for digging in @georgeguimaraes !

[georgeguimaraes]

Hey, it seems my hack of removing "document_symbols" from sources does not work anymore.

With a default repro.lua (no config on my end), I got this when browsing through some dirs and files:

CleanShot.2023-11-17.at.16.06.22.mp4

You can see that the last 2 files I opened caused the Neotree window to jump back to the top.

Do you know any workaround?

[georgeguimaraes]

I think I found the problem:

When we open a new buffer that were not opened before, neovim emits a BufAdd event, which is translated into the vim_buffer_added event in neo-tree.

That event is used in

neo-tree.nvim/lua/neo-tree/sources/filesystem/init.lua

Lines 371 to 378 in 230ff11

	if global_config.enable_opened_markers then
	for _, event in ipairs({ events.VIM_BUFFER_ADDED, events.VIM_BUFFER_DELETED }) do
	manager.subscribe(M.name, {
	event = event,
	handler = wrap(manager.opened_buffers_changed),
	})
	end
	end

For some reason, that handler seems to be forcing a redraw, which causes the window to "jump to the top".

So a simple workaround I found is using this config:

   opts = {
   	enable_opened_markers = false,
   },

That disables the above handler.

Also, I can see that #996 is caused by a different issue.

[georgeguimaraes]

Ok, now with a full-blown neovim config with lsps and so on, I still get the window scrolling to the top. That's because there's still this handler that calls manager.redraw:

neo-tree.nvim/lua/neo-tree/sources/filesystem/init.lua

Lines 355 to 361 in 230ff11

	--Configure event handlers for lsp diagnostic updates
	if global_config.enable_diagnostics then
	manager.subscribe(M.name, {
	event = events.VIM_DIAGNOSTIC_CHANGED,
	handler = wrap(manager.diagnostics_changed),
	})
	end

So, I also had to disable it using:

    opts = {
      enable_diagnostics = false,
      enable_opened_markers = false,
    },

Now my neo-tree window is not scrolling to the top anymore.

Is there a way to make manager.redraw to not have this problem?

[cseickel]

@georgeguimaraes to be clear it does not ever jump to the top for me, and probably not for many other people or we would have a lot more activity on this issue.

My first guess is that maybe there is a character in the path of your home directory that is causing a bug. We've had (still have?) bugs with non-ascii characters in paths before. I can especially see a problem if you have characters that are double width because lua handles string sizes in bytes and not characters.

Can you share the path to your home directory? What does ~ expand to?

[georgeguimaraes]

❯ echo ~
/Users/george
❯ z analytics
❯ pwd
/Users/george/code/sourcelevel/analytics

The paths I'm using don't use non-ascii characters.

I may not have been clear, but the jumping to the top only happens when you open files that you need to scroll down to reach. So maybe not a lot a people are using neo-tree with a big nested dir structure? (I like to open a lot of dirs and keep them open).

[georgeguimaraes]

@cseickel All the problems I reported are solved when I use neovim v0.9.4. The redraws are not "moving" the window anymore.

I was using neovim head before.

[cseickel]

Fascinating...

[ghidalgo93]

+1 Also having this issue, wanted to add my $0.02 and experience: for any directory/project in which the explorer items exceed the max line number, if you open a file below that max line number the file tree will jump to the top of the explorer.

@georgeguimaraes I tried setting the following which you had suggested:

    opts = {
      enable_diagnostics = false,
      enable_opened_markers = false,
    },

but continue to see the jump to the top of the explorer. It sounds like you rolled back to v0.9.4.? Going to try that and see if I can get this fixed.

[ghidalgo93]

Another note of interest, I was able to reproduce this using the minimal setup above, my own personal config, as well as using the default LazyVim setup I was playing around with this last week. A coworker was confused when I asked them if they had experienced this and had them navigate to a project with explorer items that exceeded their max line number and was able to see them reproduce it as well. My guess as to why this isn't more widely reported would be the same as @georgeguimaraes 's, in that maybe not a lot of people are using neo-tree with explorer items that exceed their max line number.

[georgeguimaraes]

Hi @ghidalgo93, yes, I rolled back to v.0.9.4 and it fixed the issues. That's what I'm currently using right now. Can you try it too?

In the newer Neovim version, my guess is that in your case, there are other events issuing the redraws. I'd try this to narrow down the possible events:

    opts = {
      sources = { "filesystem"},
      enable_diagnostics = false,
      enable_modified_markers = false,
      enable_opened_markers = false,
    },

[georgeguimaraes]

@ghidalgo93 btw, you should check #996. @miversen33 is doing work over there related to this issue.

[ghidalgo93]

Hmm, very strange - removed my nightly install for v0.9.4 and am still getting the same jumping behavior, I'm also seeing this behavior if I switch to nvim-tree however so I'm now curious if its a LazyVim issue. Will try back on my regular config when I get the chance. Thanks!

[ahacking]

@ghidalgo93 Same problem here, also using LazyVim out of the box, jumps around all over the place on a large tree after opening a file.

[georgeguimaraes]

Found the problem.

I've bisected neovim and found the first commit that introduced the problem. It's commit neovim/neovim@0081549 (neovim/neovim#24824) and neovim/neovim#24889 that changed how nvim_buf_set_lines works, and that's what Nui.nvim uses under the hood.

This change caused problems in various plugins, and I think we'll still see more plugins with problems to come.

I've opened PR #1274 with a fix for this issue.

[miversen33]

Would it make more sense to instead forward a commit to nui.nvim to correct this issue instead of patching around it?

Also good work! This was baffling me for quite some time

[georgeguimaraes]

Thanks!

Not sure if Nui.nvim should take care of this. I'm actually thinking that Neovim is at fault here. I'm not used to what should be the "correct" behavior for nvim_buf_set_lines, though.

Maybe @MunifTanjim can give some input here?

[miversen33]

I'm not used to what should be the "correct" behavior for nvim_buf_set_lines, though.

This is a very good point. In either case though, Neo-tree is using nui to handle the buffer manipulation and as such, if there is an issue with the buffer manipulation it is between nui and neo-tree (IMO). Definitely something to have @cseickel weigh in on as well.

It might also make some sense to bring this up on the actual neovim repo too (if there isn't already an issue), even if just to get some clarity on what the expected behavior of nvim_buf_set_lines should be. There is alot of code changes in those 3 commits and I don't have the time currently to pick through them but maybe one of the neovim team can shed some light on what is going on here

[georgeguimaraes]

So it seems that the default behavior now is to display the lines that were inserted at the top of the buffer when using nvim_buf_set_lines:

https://github.com/neovim/neovim/pull/24912/files#diff-3ed34500d7e4a48a8705a381853d0d16021225d4140677d4df454806bbd66927R1252

[MunifTanjim]

I opened a related discussion neovim/neovim#25883 a while back. Got no response tho.

Those behavior changes of nvim_buf_set_lines and nvim_buf_set_text are causing issues with a whole bunch of plugins.