[vim/vim] Unintuitive behavior of navigating the jumplist (not obvious if cursor will be centered or not) (Issue #14132)

28 views
Skip to first unread message

camoz

unread,
Mar 3, 2024, 2:52:43 AMMar 3
to vim/vim, Subscribed

Steps to reproduce

When navigating the jumplist, it is not obvious when the cursor will be centered in the view and when not. (With "view" I mean what is displayed on the screen.)

Exact steps to reproduce:

  • vim --clean +'set nu'
  • 59o<ESC> (now the buffer contains 60 empty lines)
  • Resize window so that the view contains 26 (empty) lines.
  • :30 (go to line 30)
  • Now, gg<C-o> will position the cursor at the bottom of the view (respecting scrolloff which is set to 5 by default), and similarly G<C-o> will position the cursor at the top of the view (again respecting scrolloff).
  • Repeating the same but with 100 empty lines in the buffer (instead of 60) and starting from line 50 (instead of 30), gg<C-o> and G<C-o> will position the cursor in the middle of the view.

Since in all cases we jump to a location that is not in the current view, the different behavior seems odd to me.

Expected behaviour

I would expect a more intuitive behavior, i.e. a behavior that is deterministic, obvious and useful. Right now, the behavior is not obvious and not always useful, IMO. Ideas:

  1. The cursor will always be centered when jumping to a line that is currently not in the view, but otherwise not.
    • If scrolloff is not 0, this might cause a bit of scrolling without centering the cursor.
  2. The cursor will always be centered in case jumping to the destination would cause the view to scroll, but otherwise not.
    • This differs from the previous point only in case scrolloff is not 0, and might be even more ergonomic or "easier for the eye" in this case, since when the view scrolls, one immediately knows that the cursor will be centered in the screen, thus one does not have to search for the cursor. It might sound a bit nitpicky since it takes only a fraction of a second to locate the new cursor position, but it might lower the cognitive load and may add up if done hundreds of times a day.
  3. The cursor will always be centered when jumping.
  4. The cursor will never be centered when jumping.

Ideally, the behavior could be configured using e.g. jumpoptions.

Version of Vim

9.1 Included patches: 1-80

Environment

OS: Archlinux
Terminal: foot 1.16.2
$TERM: foot-extra
Shell: bash 5.2.26

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.Message ID: <vim/vim/issues/14132@github.com>

Christian Brabandt

unread,
Mar 5, 2024, 3:37:29 PMMar 5
to vim/vim, Subscribed

Hm, thanks for your suggestion. I have mad a very quick patch here: chrisbra@fe4a04a

This misses test so is not yet ready to be included, but you may want to try it out.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/14132/1979594828@github.com>

Gary Johnson

unread,
Mar 5, 2024, 5:28:51 PMMar 5
to reply+ACY5DGCE2W6ZXJ3JLC...@reply.github.com, vim...@googlegroups.com
On 2024-03-05, Christian Brabandt wrote:
> Hm, thanks for your suggestion. I have mad a very quick patch here:
> chrisbra@fe4a04a
>
> This misses test so is not yet ready to be included, but you may want to try it
> out.

We should probably understand what Vim is doing now and why before
making severe changes and possibly reinventing rules.

While I agree that Vim's behavior can appear random, I do appreciate
that it seems to try to minimize scrolling and surprising jumps.
For example, when using % to jump between the top and bottom of
a block delimited by { and } or by #if and #endif, if the target
line is just off the top or bottom of the screen, Vim will scroll
the screen just a bit so that the target line and the cursor are at
the top or bottom line of the screen, as appropriate.

My guess is that there is a parameter somewhere in the code that
tells Vim, "if the screen would need to be scrolled less than
N lines to display the target line, scroll as little as possible;
otherwise, jump and center the cursor."

Maybe it would be sufficient to let users adjust that parameter, if
it exists.

Regards,
Gary

vim-dev ML

unread,
Mar 5, 2024, 5:29:04 PMMar 5
to vim/vim, vim-dev ML, Your activity

On 2024-03-05, Christian Brabandt wrote:
> Hm, thanks for your suggestion. I have mad a very quick patch here:
> ***@***.***

>
> This misses test so is not yet ready to be included, but you may want to try it
> out.

We should probably understand what Vim is doing now and why before
making severe changes and possibly reinventing rules.

While I agree that Vim's behavior can appear random, I do appreciate
that it seems to try to minimize scrolling and surprising jumps.
For example, when using % to jump between the top and bottom of
a block delimited by { and } or by #if and #endif, if the target
line is just off the top or bottom of the screen, Vim will scroll
the screen just a bit so that the target line and the cursor are at
the top or bottom line of the screen, as appropriate.

My guess is that there is a parameter somewhere in the code that
tells Vim, "if the screen would need to be scrolled less than
N lines to display the target line, scroll as little as possible;
otherwise, jump and center the cursor."

Maybe it would be sufficient to let users adjust that parameter, if
it exists.

Regards,
Gary


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/14132/1979744031@github.com>

Asheq Imran

unread,
Jun 30, 2024, 7:40:22 PM (2 days ago) Jun 30
to vim/vim, vim-dev ML, Comment

@camoz @chrisbra My personal ideal behavior is to always center after jumping, unless bringing the destination line into view can be done while keeping some of the original view visible, in which case, scroll only as far as needed to bring the destination into view, i.e., the destination will be the bottom or top line of the window.

Example (assume scrolloff is 0 and wrap is off for simplicity):

The current view shows lines 21 through 30 (total 10 lines)

  • Jumping to line 39 would not cause centering because vim could show lines 30 through 39, where 30 was part of the original view.
  • Jumping to line 40 would cause centering because it's impossible to show some of the original view when jumping this far (showing 31 to 40 is the best vim can do). Vim should center in this case because the user loses no context from the original view any way.

In general, jumping to any line between 12 through 39 would not cause centering, whereas jumping to lines below 12 or above 39 would cause centering.

I realize that wrapped lines would make calculating this less straightforward since a line could take up a variable amount of window/screen lines.

I think vim is currently intending to do some semblance of this. It seems like it is trying do something like "center if showing the destination line would require more than about half a window height lines of scrolling" but it doesn't appear to be exact, and perhaps there are weird edge cases and bugs that have built up over time, perhaps partly due to oversight when adding options like wrap, scrolloff, etc.


Reply to this email directly, view it on GitHub.

You are receiving this because you commented.Message ID: <vim/vim/issues/14132/2198805855@github.com>

Reply all
Reply to author
Forward
0 new messages