Scrolling behavior in Vim
59 views
Skip to first unread message
Marc Adler
Oct 13, 2025, 9:28:49 AMOct 13
to vim_dev
(I asked this on the Vim Use list and got recommended to ask here.)
I use Vim to write text, ie prose with paragraphs.
Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
Smoothscroll fixes this, but only when you're scrolling down.
Is there a way to make it work when scrolling up?
Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
Vim:
VSCode:
Is there a way to fix this? Like I said, this behavior is unique to Vim.
Christian Brabandt
Oct 14, 2025, 2:12:56 AMOct 14
to vim...@googlegroups.com
thanks,
Christian
--
My, how you've changed since I've changed.
Marc Adler
Oct 14, 2025, 3:48:24 PMOct 14
to vim_dev
Yes, I used set smoothscroll, but it only works in one direction (down) when scrolling via cursor movement. When scrolling up that way, the effect is lost.
Also, using ctl-e/y isn't a substitute for the behavior I'm talking about, since once you put your cursor into the "paragraph" (= really long line), Vim will jerkily reposition that paragraph so the beginning of it is on the screen, which is the behavior I'm trying to avoid.
One thing I don't understand is why only Vim has this behavior. Emacs, VSCode, etc. don't. They're poor substitutes for Vim, so this is a little frustrating.
Christian Brabandt
Oct 14, 2025, 3:58:00 PMOct 14
to vim...@googlegroups.com
On Di, 14 Okt 2025, Marc Adler wrote:
> Yes, I used set smoothscroll, but it only works in one direction
> (down) when scrolling via cursor movement. When scrolling up that way,
> the effect is lost.
> Also, using ctl-e/y isn't a substitute for the behavior I'm talking
> about, since once you put your cursor into the "paragraph" (= really
> long line), Vim will jerkily reposition that paragraph so the
> beginning of it is on the screen, which
> is the behavior I'm trying to avoid.
paragraphs/lines just fine.
> One thing I don't understand is why only Vim has this behavior. Emacs,
> VSCode, etc. don't. They're poor substitutes for Vim, so this is a
> little frustrating.
behaviour on its own.
Thanks,
Christian
--
Yow! Is this sexual intercourse yet?? Is it, huh, is it??
Marc Adler
Oct 15, 2025, 6:41:09 PMOct 15
to vim_dev
On Tuesday, October 14, 2025 at 2:58:00 PM UTC-5 Christian Brabandt wrote:
On Di, 14 Okt 2025, Marc Adler wrote:
That is a cursor movement, not scrolling.
I know, that's why I described it that way and provided the videos to explain what I'm talking about.
Cannot reproduce this. Ctrl-E/Ctrl-Y works for me for scrolling long
paragraphs/lines just fine.
It's when you put the cursor in the long paragraph after scrolling that it jumps.
Because each program is different and each editor has to implement this
behaviour on its own.
Actually all the programs are the same in this regard. It's only Vim that's different.
Regards,
Marc
Christian Brabandt
Oct 16, 2025, 4:50:58 AMOct 16
to vim...@googlegroups.com
On Mi, 15 Okt 2025, Marc Adler wrote:
>
>
> On Tuesday, October 14, 2025 at 2:58:00 PM UTC-5 Christian Brabandt wrote:
>
>
> On Di, 14 Okt 2025, Marc Adler wrote:
>
> That is a cursor movement, not scrolling.
>
>
> I know, that's why I described it that way and provided the videos to explain
> what I'm talking about.
>
> Cannot reproduce this. Ctrl-E/Ctrl-Y works for me for scrolling
> long
> paragraphs/lines just fine.
>
>
> It's when you put the cursor in the long paragraph after scrolling that it
> jumps.
vim --clean --cmd ':set smoothscroll' example.txt
And please provide some sample text (e.g. using lorem ipsum generator)
and provide the terminal size (e.g. $LINES=20 and $COLUMNS=40).
Thanks,
Christian
--
It is better to never have tried anything than to have tried something and
failed.
-- motto of jerks, weenies and losers everywhere
Marc Adler
Oct 21, 2025, 11:34:34 AMOct 21
to vim_dev
Imgur appears to be down so I've uploaded the video to one of my unused websites.
At the very beginning I do :echo winheight(0) winwidth(0) at the bottom so you can see the size.
Then I "scroll" up and down using j and k (which I've remapped to gj and gk) just to show how the display jumps between paragraphs.
Then I use ctl-e/y to scroll that way. Then you can see my cursor (the one operated by my mouse) move to a paragraph at the top which is only partly displayed. When I click in there in order to move the Vim cursor into that position, the display jumps again to display the whole paragraph.
This behavior is being caused by Vim's desire to bring the beginning of any line where the cursor is into the display window.
Let me know if you have any questions.
Christian Brabandt
Oct 26, 2025, 4:35:59 PMOct 26
to vim...@googlegroups.com
On Di, 21 Okt 2025, Marc Adler wrote:
> Imgur appears to be down so I've uploaded the video to one of my unused websites.
>
> https://www.texasmidnight.com
>
> At the very beginning I do :echo winheight(0) winwidth(0) at the bottom so you can see the size.
>
> Then I "scroll" up and down using j and k (which I've remapped to gj and gk) just to show how the display jumps between paragraphs.
>
> Then I use ctl-e/y to scroll that way. Then you can see my cursor (the one operated by my mouse) move to a paragraph at the top which is only partly displayed. When I click in
> there in order to move the Vim cursor into that position, the display jumps again to display the whole paragraph.
>
> This behavior is being caused by Vim's desire to bring the beginning of any line where the cursor is into the display window.
>
> Let me know if you have any questions.
I find it hard to follow what exactly you did, but it does not seem to
be related (directly) to smooth scrolling but rather to using the mouse
to position the cursor?
Thanks,
Christian
--
There is no hunting like the hunting of man, and those who have hunted
armed men long enough and liked it, never care for anything else thereafter.
-- Ernest Hemingway
Marc Adler
Oct 28, 2025, 5:54:42 PMOct 28
to vim_dev
What it boils down to is that Vim always wants to display the beginning of any line the cursor is on. If you have a very long line which wraps many times (as is common in writing prose, since Vim treats such "paragraphs" as single lines) and the beginning of the line is off the screen to the top, the display will jump as soon as you put the cursor into that line (eg by jk'ing up from below) as Vim brings the entire line into view. I don't think recording more videos will help, since the one I posted shows everything you need to know to understand the problem.
Let me show you this way:
------------top------------
This is the FIRST paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph. █
This is the SECOND paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph.
This is the THIRD paragraph
of this text. It is
actually one single line
from Vim's perspective, but
---------bottom------------
Fig. 1 - Screen State 1
Let's assume that I scroll the screen down from Screen State 1 to Screen State 2:
------------top------------
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph.
This is the SECOND paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph.
This is the THIRD paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph. █
---------bottom------------
Fig. 2 - Screen State 2
As you can see, I've scrolled down by three lines. From Vim's perspective, it isn't three "lines," it's just the first section of the first line that has scrolled up off the screen.
Remember, Vim has a desire to display the beginning of the line the cursor is on that's so strong that only a heroine addict could understand, so when I move the cursor back up to the first paragraph, instead of display Screen State 3 or 4 (see below), it will jerkily jump the display up to Screen State 1 (see above).
------------top------------
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph. █
This is the SECOND paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph.
This is the THIRD paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
---------bottom------------
Fig. 3 - Screen State 3
------------top------------
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph. █
This is the SECOND paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph.
This is the THIRD paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
---------bottom------------
Fig. 4 - Screen State 4
In other words, Vim will not simply move the display up line by line. It will jump up by however many lines it takes to get the beginning of what it sees as a line onto the screen.
Again, the behavior I'm suggesting Vim use is the behavior found *by default* in Emacs, Windows Word, every single browser, VSCode, every single e-reader when set to scroll mode, etc., etc. I understand that not a lot of people use Vim the way I do, and when writing code, lines should never go beyond 80 characters anyway, so it doesn't matter when writing code, but the question does arise: why is Vim (and only Vim) this way? It's a mystery. Another question: why don't I just use those other editors? Because I've tried them all, and Vim is the best. This bizarre quirk in Vim not a deal-breaker, but it is irritating, especially since there doesn't seem to be a reason for it to exist (since no other editor has it).
Anyway, I hope you now understand the issue I'm describing. Let me know if you have any other questions.
Marc Adler
Let me show you this way:
------------top------------
This is the FIRST paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph. █
This is the SECOND paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph.
This is the THIRD paragraph
of this text. It is
actually one single line
from Vim's perspective, but
---------bottom------------
Fig. 1 - Screen State 1
Let's assume that I scroll the screen down from Screen State 1 to Screen State 2:
------------top------------
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph.
This is the SECOND paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph.
This is the THIRD paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph. █
---------bottom------------
Fig. 2 - Screen State 2
As you can see, I've scrolled down by three lines. From Vim's perspective, it isn't three "lines," it's just the first section of the first line that has scrolled up off the screen.
Remember, Vim has a desire to display the beginning of the line the cursor is on that's so strong that only a heroine addict could understand, so when I move the cursor back up to the first paragraph, instead of display Screen State 3 or 4 (see below), it will jerkily jump the display up to Screen State 1 (see above).
------------top------------
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph. █
This is the SECOND paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph.
This is the THIRD paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
---------bottom------------
Fig. 3 - Screen State 3
------------top------------
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph. █
This is the SECOND paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
several sentences forming
a paragraph.
This is the THIRD paragraph
of this text. It is
actually one single line
from Vim's perspective, but
since it's prose, it's
---------bottom------------
Fig. 4 - Screen State 4
In other words, Vim will not simply move the display up line by line. It will jump up by however many lines it takes to get the beginning of what it sees as a line onto the screen.
Again, the behavior I'm suggesting Vim use is the behavior found *by default* in Emacs, Windows Word, every single browser, VSCode, every single e-reader when set to scroll mode, etc., etc. I understand that not a lot of people use Vim the way I do, and when writing code, lines should never go beyond 80 characters anyway, so it doesn't matter when writing code, but the question does arise: why is Vim (and only Vim) this way? It's a mystery. Another question: why don't I just use those other editors? Because I've tried them all, and Vim is the best. This bizarre quirk in Vim not a deal-breaker, but it is irritating, especially since there doesn't seem to be a reason for it to exist (since no other editor has it).
Anyway, I hope you now understand the issue I'm describing. Let me know if you have any other questions.
Marc Adler
Nick Jensen
Oct 28, 2025, 6:39:29 PMOct 28
to Marc Adler, vim...@googlegroups.com
The 2025-10-28 14:54, Marc Adler wrote:
>What it boils down to is that Vim always wants to display the beginning of
>any line the cursor is on.
With a bit of testing I think the options you are looking for are:
>What it boils down to is that Vim always wants to display the beginning of
>any line the cursor is on.
set nostartofline breakindent smoothscroll
>the question does arise: why is Vim (and only Vim) this way? It's a mystery.
The other editors you've mentioned do not have the line editor history.
Regards,
Nick
Marc Adler
Oct 28, 2025, 7:17:17 PMOct 28
to vim_dev
On Tuesday, October 28, 2025 at 5:39:29 PM UTC-5 Nick Jensen wrote:
With a bit of testing I think the options you are looking for are:
set nostartofline breakindent smoothscroll
I tried it, but it didn't work. The problem isn't that Vim is putting my cursor at the beginning of the line. It doesn't. If I gk up into a paragraph that is only partially displayed, the cursor is where I expect it (somewhere on the bottom line of that paragraph) but the rest of the paragraph is displayed.
Interestingly, smoothscroll works (when using gj and gk to "scroll") when scrolling down but not up.
The answer is that vim has evolved from ed and ex which are line editors.
The other editors you've mentioned do not have the line editor history.
Interesting. So does that mean that this behavior is too deep inside Vim to change?
Marc
Nick Jensen
Oct 28, 2025, 9:20:21 PMOct 28
to Marc Adler, vim...@googlegroups.com
The 2025-10-28 16:17, Marc Adler wrote:
> > With a bit of testing I think the options you are looking for are:
> >
> > set nostartofline breakindent smoothscroll
>
>I tried it, but it didn't work.
Ah no it doesn't either. There are some strange inconsistencies with
> > With a bit of testing I think the options you are looking for are:
> >
> > set nostartofline breakindent smoothscroll
>
>I tried it, but it didn't work.
smoothscroll - gk works as expected sometimes, if the paragraph is
already partially visible when navigating into it, but not other times,
especially when just using gk to scroll up the page. It's the same with
clicking in the paragraph with the mouse - sometimes it just moves the
cursor, other times it scrolls so the start of the line is visible.
> > The answer is that vim has evolved from ed and ex which are line editors.
>
> Interesting. So does that mean that this behavior is too deep inside Vim to
> change?
I don't think so, features like smoothscroll are very new and are added
> change?
over time. But any new option has to be "optional" and not change the
existing behaviour unexpectedly.
Marc Adler
Oct 29, 2025, 12:05:48 PMOct 29
to vim_dev
On Tuesday, October 28, 2025 at 8:20:21 PM UTC-5 Nick Jensen wrote:
I don't think so, features like smoothscroll are very new and are added
over time. But any new option has to be "optional" and not change the
existing behaviour unexpectedly.
It would be great if this were fixed, since it wouldn't affect Vim's behavior for programmers and it would liberate writers from having to use Emacs or VSCode or whatever.
Out of curiosity, do you know where in the source code this behavior is defined?
Christian Brabandt
Oct 29, 2025, 3:55:30 PMOct 29
to vim...@googlegroups.com
On Mi, 29 Okt 2025, Marc Adler wrote:
> On Tuesday, October 28, 2025 at 8:20:21 PM UTC-5 Nick Jensen wrote:
>
>
> I don't think so, features like smoothscroll are very new and are added
> over time. But any new option has to be "optional" and not change the
> existing behaviour unexpectedly.
>
>
> It would be great if this were fixed, since it wouldn't affect Vim's
> behavior for programmers and it would liberate writers from having to
> use Emacs or VSCode or whatever.
the todo list. Just someone has to find the time to track it down and
fix it finally. Sounds simple, doesn't it?
> Out of curiosity, do you know where in the source code this behavior
> is defined?
release of v9 I believe. The code itself is not trivial and it took a
few additional patches to fix related issues with this new feature.
That's why, having a reproducible example helps with debugging and
creating tests to make sure this does not regress, *hint*.
Where exactly in the code depends on what action triggers it,
potentially somewhere in move.c
Thanks,
Christian
--
Rome wasn't burnt in a day.
Reply all
Reply to author
Forward
0 new messages