neovim

neovim copied to clipboard

Problem

When buffer contains closed folds (especially noticable when there are a lot of closed folds one after another). Previously <C-u> jumped/scrolled half of the screen no matter is line folded or not (so folds treated like 1 line), but currently <C-u> is stopped at each closed fold. <C-d> behave like it was previously (if we omit the situation about scrolling below the end of file).

Steps to reproduce

You can test it with file like https://github.com/monkoose/neocodeium/blob/main/lua/neocodeium/server.lua or create some file with some folds one after another

• nvim --clean server.lua
• yank/paste few times folds in this file for greater visibility of the issue
• Close all folds
• From start of the file use <C-d> and then use <C-u> few times.

Expected behavior

<C-u> should jump/scroll half of the window height even when closed folds are present.

Neovim version (nvim -v)

NVIM v0.10.0-dev-2823+g7560aee595

Vim (not Nvim) behaves the same?

no, vim 9.1.145 (some version before that notorious PR)

Operating system/version

Linux

Terminal name/version

st

$TERM environment variable

st-256color

Installation

AUR

Please include steps from nvim --clean, does it depend on some options? Scrolling with Ctrl-D/U is symmetric for me in the presence of closed folds and is scrolling the expected 'scroll' amount of lines.

They are already included. For me it scrolls like I described. Folds content should be greater than 'scroll' for <C-u> to stop on each closed fold.

Are you talking about the topline (line('w0')) or the cursor position? I think I see what you describe for the cursor position near the top of the file only, is that what you mean? I don't see any asymmetric scrolling behavior, or the topline stopping on a closed fold. The cursor issue I do see is also fixed in the latest (yet to be merged/ported) Vim patch.

I just tested with https://github.com/neovim/neovim/releases/download/nightly/nvim-linux64.tar.gz nvim and it has the same issue.

I'm talking about cursor position. @luukvbaal

• Open empty file
• Type 'hello world'
• yy
• 2000p
• gg qq zf100j j q 100@q
• hit <C-u> multiple times notice that it moves one fold per <C-u>
• gg <C-d> jumps expected amount of lines.

hit <C-u> multiple times notice that it moves one fold per <C-u>

So "it" is the cursor position then? This I can reproduce near the top of the file once the buffer content itself no longer needs to scroll. This should be fixed once #28160 is finalized/merged, probably including https://github.com/vim/vim/pull/14410.

The confusion came from the issue mentioning "Previously <C-u> jumped/scrolled half of the screen". When talking about scrolling in a window, I assumed we're talking about the topline.

Open empty file Type 'hello world' yy 2000p gg qq zf100j j q 100@q hit <C-u> multiple times notice that it moves one fold per <C-u> gg <C-d> jumps expected amount of lines.

Now this example doesn't move cursor from first closed fold at all with <C-d> or from last line with <C-u> if last line is not in a fold.

Can you link why this changes was made in the first place, and what previously wasn't working? Documentation specifically says that cursor should follow the same scroll amount.

Scroll window Downwards in the buffer. The number of lines comes from the 'scroll' option (default: half a screen). If [count] given, first set 'scroll' option to [count]. The cursor is moved the same number of lines down in the file (if possible; when lines wrap and when hitting the end of the file there may be a difference).

The original motivation was resolving #27967, while adding 'smoothscroll' support to the various scroll keys. But the original patch was merged in a backward incompatible state, so now we're fixing the issues on master, which is not ideal of course...

I think the issue you mention now should be fixed by https://github.com/vim/vim/pull/14455.

Can we reopen this issue until then?

The original motivation was resolving https://github.com/neovim/neovim/issues/27967

Ah, notorious virtual text above. Adds 0.0001% usefulness and 99% of bugs.

Can we reopen this issue until then?

There is #28250 already.

The issue is fixed with 832857ae094743bd17e36a0096d1da38fc383178

Thanks for your work.