Weird jumps when collapsing node

[MunifTanjim]

I reported this before, but it's not completely fixed: #996

I tracked it down to this piece of codes:

neo-tree.nvim/lua/neo-tree/ui/renderer.lua

Lines 542 to 547 in 459c603

	execute_win_command("normal! zb")
	local top = vim.fn.line("w0", state.winid)
	local bottom = vim.fn.line("w$", state.winid)
	local offset_top = top + (expected_bottom_line - bottom)
	execute_win_command("normal! " .. offset_top .. "zt")
	pcall(vim.api.nvim_win_set_cursor, state.winid, { linenr, col })

If I comment it out, everything works perfectly as expected.

Anybody knows what that piece of code does?

neo-tree.nvim/lua/neo-tree/ui/renderer.lua

Line 542 in 459c603

execute_win_command("normal! zb")

This moves the current node at the bottom of screen.

neo-tree.nvim/lua/neo-tree/ui/renderer.lua

Line 546 in 459c603

execute_win_command("normal! " .. offset_top .. "zt")

Then this moves another line at the top of screen.

These causes unnecessary jumps and it's very problematic.

[MunifTanjim]

@cseickel @pysan3 @miversen33

[pysan3]

As we now have renderer.position.save() which saves the topline and lnum via vim.fn.winsaveview(), I think it is safe to remove that chunk or any other attempts to try to preserve the cursor position.

I think many of the workaround-ish code to save the cursor position was doing a race condition which I should have solved with #1355 so we should have consistent and predictable results now.

But I'm not the one who wrote (nor have I ever interacted with) this code so I can't say for sure.

Redirecting this to @cseickel

[cseickel]

zb moves your cursor to the bottom of the window, respecting scrolloff
<line>zt moves the cursor to the indicated line and sets that line as the top of the window, respecting scrolloff

Why?

This chunk of code is not about saving the top line at all, it is the opposite. It moves the top line if either of these situations occur:

1. The window is scrolled down even though the entire tree can now fit in the window without scrolling.
2. The focused node is scrolled off of the screen, after we take into account the requested extra padding

Fixing the scrolled down to far problem is mostly about opening and closing folders which change the overall size of the tree and can lead to be scrolled down when you don't need to be.

The "requested extra padding" is for the sake of the search popup which floats over top of the bottom of the window. You need the extra padding to ensure that the focused node is not under the floating window.

How?

Given that understanding, I will attempt to walk through the code.

      -- make sure we are not scrolled down if it can all fit on the screen
      local lines = vim.api.nvim_buf_line_count(state.bufnr)
      local win_height = vim.api.nvim_win_get_height(state.winid)
      local expected_bottom_line = math.min(lines, linenr + 5) + bottom_scroll_padding
      if expected_bottom_line > win_height then
        execute_win_command("normal! zb")
        local top = vim.fn.line("w0", state.winid)
        local bottom = vim.fn.line("w$", state.winid)
        local offset_top = top + (expected_bottom_line - bottom)
        execute_win_command("normal! " .. offset_top .. "zt")
        pcall(vim.api.nvim_win_set_cursor, state.winid, { linenr, col })
      elseif win_height > linenr then
        execute_win_command("normal! zb")
      elseif linenr < (win_height / 2) then
        execute_win_command("normal! zz")
      end

• First off, it's important to note that when we get here the focused node has already been set and it can be anywhere on the screen.
• expected_bottom_line is where we want the focused node to be if it can't be visible by scrolling the window all the way to the top, which is the ideal goal.
• IF that expected_bottom_line is off of the screen, then:
  • normal! zb move the current focused line to the bottom of the window, preserving the user's scrolloff setting.
  • Then we take a measurement and see in this hypothetical situation where the focused node is at our ideal "bottom" of the screen, what would our top line be?
  • Now we move the cursor to that top line, respecting scrolloff. Why? I have no idea. Maybe everything after normal! zb should be removed.
  • Then we set the cursor back to where we started.

I could have misinterpreted, even though I think I did write this code.

[pysan3]

OK, I've looked into the code and here's the problem.

expected_bottom_line should actually be the most bottom line cursor can be in order to not conflict with bottom_scroll_padding (ie search bar height).

Current code forces cursor position to be on this line, even when there are actually more content below the cursor to spare and there were no reason to be afraid of bottom_scroll_padding.

This diff should solve the problem. Could you check it out @MunifTanjim ?

Modified       lua/neo-tree/ui/renderer.lua
@@ -542,7 +542,10 @@ M.focus_node = function(state, id, do_not_focus_window, relative_movement, botto
       local lines = vim.api.nvim_buf_line_count(state.bufnr)
       local win_height = vim.api.nvim_win_get_height(state.winid)
       local expected_bottom_line = math.min(lines, linenr + 5) + bottom_scroll_padding
-      if expected_bottom_line > win_height then
+      local virtual_last_line = vim.fn.line("w0", state.winid) + win_height
+      if expected_bottom_line > win_height and virtual_last_line < lines then
+        -- skip: whole tree doesn't fit in the window
+        -- and there's more lines to spare below the cursor than `expected_bottom_line`.
+      elseif expected_bottom_line > win_height then
         execute_win_command("normal! zb")
         local top = vim.fn.line("w0", state.winid)
         local bottom = vim.fn.line("w$", state.winid)

normal! zb and other code are necessary when the tree had more height than the window and the last line was below window's bottom line, but after closing the node, the buffer length shrunk and last line is now visible. Neotree will scroll down a bit so that there are no blank lines below the tree.

[pysan3]

I ended up with a much cleaner solution.

      local lines = vim.api.nvim_buf_line_count(state.bufnr)
      local win_height = vim.api.nvim_win_get_height(state.winid)
      local virtual_last_line = vim.fn.line("w0", state.winid) + win_height - bottom_scroll_padding
      if virtual_last_line <= linenr then
        execute_win_command("normal! " .. (linenr + bottom_scroll_padding) .. "zb")
        pcall(vim.api.nvim_win_set_cursor, state.winid, { linenr, col })
      elseif virtual_last_line > lines then
        execute_win_command("normal! " .. (lines + bottom_scroll_padding) .. "zb")
        pcall(vim.api.nvim_win_set_cursor, state.winid, { linenr, col })
      elseif linenr < (win_height / 2) then
        execute_win_command("normal! zz")
      end

This should work all as expected. @MunifTanjim

Edit: TODO rename it to virtual_bottom_line.

[pysan3]

@cseickel Were you able to reproduce the issue?

Here's how I reproduced it with the linux kernel.

1. :Neotree reveal_file=drivers/gpu/drm/nouveau/include/nvrm/535.113.01/common/sdk/nvidia/inc/ctrl/ctrl2080/ctrl2080internal.h
2. Cursor should be at the center of window (as if zz).
3. close_node
4. Cursor should be on ctrl2080/ but the window scrolled downwards as if zb (where I don't want the buffer to move).

[MunifTanjim]

This should work all as expected.

Working nicely for me so far 🚀

[pysan3]

Thanks @MunifTanjim

#1377