[vim/vim] Whole-page scrolling is off by one line (Issue #14585)
Mathias Rav
Steps to reproduce
- Open Vim 9.1.0346 to a buffer of 1000 lines:
git checkout v9.1.0346 && make -j && make install prefix=$HOME/myvim && seq 1000 | ~/myvim/bin/vim --clean - - Press CTRL-F CTRL-B
Expected behaviour
Same behavior as v9.1.0210: After pressing CTRL-F, the cursor is at first line of the screen, and after pressing CTRL-B, the cursor is at the last line of the screen (in my case, line 40 on a window that shows 40 lines)
Actual behavior since v9.1.0211: After pressing CTRL-F, the cursor is at first line of the screen, and after pressing CTRL-B, the cursor is at the second-to-last line of the screen (in my case, line 39 on a window that shows 40 lines)
Version of Vim
9.1.0346
Environment
Arch Linux, GNOME Terminal
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mathias Rav
(Aside 1: I was about to file an issue with half-page scrolling against v9.1.0252 (currently the version in Arch) as well, but it seems like that is fixed in v9.1.0346, so I just need to wait for Arch Linux to rebuild the package.)
(Aside 2: Maybe I'm misremembering, but I think that older versions of Vim (before v9.1.0151) scrolled whole window minus one line when doing whole-page scrolling with CTRL-F and CTRL-B, but current version seems to do whole window minus two lines. It's not something that's critical for my use of Vim so I'm not going to file an issue for that.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
I checked a 40-line window created using the following script:
40new call setline(1, range(1, 1000))
On both v9.1.0151 and v9.1.0252, Ctrl-F changes topline from line 1 to line 39.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mathias Rav
Hi @zeertzjq, thanks for the quick reply. Perhaps my bug report was unclear. The problem arises when pressing CTRL-F followed by CTRL-B. After CTRL-B, I expect the cursor to be on the bottommost visible line on the screen, and NOT the second line from the bottom of the screen.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
luukvbaal
Yes, I can confirm the cursor behavior difference. The "overlap" you mention in your second comment is handled by get_scroll_overlap() (it depends on the window size and what lines are in the viewport) and I think behaves similarly to older versions after it was restored.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
Oops, I didn't notice that you were talking about the cursor. This seems to differ with scrolloff=0:
set scrolloff=0
40new call setline(1, range(1, 1000))
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
luukvbaal
I can try to restore the cursor behavior although I still think we could benefit from a discussion in unifying the cursor behavior across the various ways to scroll the window. There was some amount of backlash against changing the behavior for Ctrl-D/U, would this backlash also be there for making Ctrl-F/B/Y/E behave as Ctrl-D/U?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
luukvbaal
and after pressing CTRL-B, the cursor is at the last line of the screen (in my case, line 40 on a window that shows 40 lines)
I also wonder why this happened. The help for CTRL-B does not mention anything about moving the cursor. So isn't it strange that it moved the cursor to line 40 while line 39 is still visible?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mathias Rav
I can try to restore the cursor behavior although I still think we could benefit from a discussion in unifying the cursor behavior across the various ways to scroll the window. There was some amount of backlash against changing the behavior for Ctrl-D/U, would this backlash also be there for making Ctrl-F/B/Y/E behave as Ctrl-D/U?
I don't think Vim should change core movement/editing behavior in the name of "unifying the various ways to do x", and I think that includes the difference in behavior of one line vs half page vs whole page scrolling. For new users, sure, the odd differences in similar operations is odd, but from my point of view I don't think Vim should cater to new users. For old users like myself with ingrained muscle memory, Vim is a constant in a rapidly evolving landscape, so these small changes are quite disruptive. If I wanted to reach for hyperbole, I would say something like "unifying scrolling? What's next - unifying the difference between cw and dw?" - but I understand that it's more nuanced than that. What do you think?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
luukvbaal
I mean to me the difference in behavior just feels like an oversight. Obviously cw and dw are intentionally different. I think the fact that backwards compatibility seems to trump making a decision that could improve the behavior is unfortunate. There could even some kind of 'scrollcursor' option to choose the desired behavior and keep the old behavior when unset but TBH that isn't even worth it. I'll make a patch to restore the old behavior.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Thanks, I very much appreciate it!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #14585 as completed via 4b6b0c4.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Asheq Imran
@luukvbaal @chrisbra Pressing when the window is already scrolled all the way to the top of the buffer moves the cursor to the bottom of the window. I don't think this is intended.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
luukvbaal
I think you're right @Asheq. #15139 should fix that.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.