luukvbaal

unread,

Jul 9, 2022, 7:30:22 AM7/9/22

to vim/vim, Subscribed

This PR originates from neovim/neovim#19243.

Adds a new option to avoid scrolling when opening/closing splits. Perceived by users of the plugin mentioned in the original PR as less visually jarring. Especially so when using the quickfix window for automatic linting(opening and closing automatically as a buffers' linting errors are resolved).

You can view, comment on, or merge this pull request online at:

https://github.com/vim/vim/pull/10682

Commit Summary

522c767 Add new option splitscroll to avoid scrolling

File Changes

(5 files)

Patch Links:

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

codecov[bot]

unread,

Jul 9, 2022, 3:41:01 PM7/9/22

to vim/vim, Subscribed

Codecov Report

Merging #10682 (522c767) into master (b908188) will increase coverage by 0.89%.
The diff coverage is 16.66%.

@@            Coverage Diff             @@

##           master   #10682      +/-   ##

==========================================

+ Coverage   81.71%   82.60%   +0.89%     

==========================================

  Files         158      148      -10     

  Lines      185631   172979   -12652     

  Branches    41980    39103    -2877     

==========================================

- Hits       151686   142891    -8795     

+ Misses      21486    17490    -3996     

- Partials    12459    12598     +139

Flag	Coverage Δ
huge-clang-none	`82.60% <16.66%> (-0.01%)`	⬇️
linux	`82.60% <16.66%> (-0.01%)`	⬇️
mingw-x64-HUGE	`?`
mingw-x64-HUGE-gui	`?`
windows	`?`

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/window.c	`87.30% <16.66%> (-1.10%)`	⬇️
src/highlight.c	`78.41% <0.00%> (-2.69%)`	⬇️
src/time.c	`87.08% <0.00%> (-2.56%)`	⬇️
src/misc2.c	`86.68% <0.00%> (-2.52%)`	⬇️
src/help.c	`80.07% <0.00%> (-2.38%)`	⬇️
src/buffer.c	`84.11% <0.00%> (-2.35%)`	⬇️
src/session.c	`63.15% <0.00%> (-1.94%)`	⬇️
src/menu.c	`81.36% <0.00%> (-1.83%)`	⬇️
src/gui.c	`71.24% <0.00%> (-1.82%)`	⬇️
src/arglist.c	`83.83% <0.00%> (-1.72%)`	⬇️
... and 131 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b908188...522c767. Read the comment docs.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jul 9, 2022, 3:48:18 PM7/9/22

to vim/vim, Subscribed

> This PR originates from https://github.com/neovim/neovim/pull/19243.

>
> Adds a new option to avoid scrolling when opening/closing splits.
> Perceived by users of the

> [plugin](https://github.com/luukvbaal/stabilize.nvim) mentioned in the

> original PR as less visually jarring. Especially so when using the
> quickfix window for automatic linting(opening and closing

> automatically as a buffers' linting errors are resolved).

I find it hard to understand the explanation of the option.
It probably helps to separately explain what happens when splitting and
when closing a window.

It is also about terminology: what is "the current scroll position"?
Is that what line the first line of the window is displaying?

Centering the cursor in the window does not mean "keep centered". What
if the cursor was not centered to start with?

If we can agree on what this does, it will need a test.

--
From "know your smileys":
y:-) Bad toupee

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 9, 2022, 6:31:53 PM7/9/22

to vim/vim, Subscribed

Thanks for considering the option. I'll try to improve the wording in the docs and look into making a test.

After some discussion under the neovim devs the current proposal is to make the option non-boolean and have the following options:

scroll to maintain relative position (current behavior)
don't scroll except as needed to keep cursor row visible (and subject to 'scrolloff')
never scroll, even if cursor row will be hidden or 'scrolloff' would be violated

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 10, 2022, 12:33:14 PM7/10/22

to vim/vim, Subscribed

I was thinking tests could go in testdir/test_window_cmd.vim looking something like:

func Test_winscroll_with_splits()
  set splitbelow
  set scrolloff=0
  set splitscroll=1
  call setline(1, range(1,256))
  norm Mk "move cursor to line above where new split will begin
  wincmd s
  wincmd p
  call assert_equal(1, line("w0"))
  wincmd q

  similar sequence when cursor is behind new split and for splitscroll={0,2} and scrolloff > 0
  %bw!
endfunc

Does that seem right?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 10, 2022, 8:43:21 PM7/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

34be31e Make splitscroll non-boolean

—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 10, 2022, 8:53:43 PM7/10/22

to vim/vim, Subscribed

@luukvbaal commented on this pull request.

In src/testdir/test_window_cmd.vim:

> +  norm gg
+  execute 'norm' l:line . 'G'
+  split
+  wincmd p
+  call assert_equal(2, line("w0"))
+  quit
+
+  set scrolloff=0
+  set splitscroll=2
+  norm ggL
+  split
+  quit
+  call assert_equal(winheight(0), line("."))
+  split
+  wincmd p
+  call assert_equal(winheight(0), line("."))

I made the option non-boolean in the latest commit as per neovim/neovim#19243 (comment). I also added some tests but I'm running into an issue.

I cant get this test to pass even though manually running the commands yields the expected results. I expect this has something to do with https://github.com/vim/vim/blob/34be31ebaa1ed3f139928d0f7a1a6d1993621e31/src/window.c#L4943-L4945
Where we move the cursor to the last visible line when moving back to the original window in the case where 'splitscroll' == 2 and the cursor was behind the newly opened split. I suspect this is not the correct way to set the cursor position and is what causes the assertion to fail when run inside a VimL function.

I suspected some function from move.c should be called to update/invalidate but I didn't find it yet. What would be the correct way to update the cursor, or am I on the wrong track?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 12, 2022, 9:23:11 PM7/12/22

to vim/vim, Subscribed

@luukvbaal commented on this pull request.

In src/testdir/test_window_cmd.vim:

> +  norm gg
+  execute 'norm' l:line . 'G'
+  split
+  wincmd p
+  call assert_equal(2, line("w0"))
+  quit
+
+  set scrolloff=0
+  set splitscroll=2
+  norm ggL
+  split
+  quit
+  call assert_equal(winheight(0), line("."))
+  split
+  wincmd p
+  call assert_equal(winheight(0), line("."))

I figured out w_botline is not the expected value here when running the test, hence the cursor is not set and the test fails. Is w_botline being outdated expected when running VimL functions?

Exchanging w_botline for w_topline + w_height resolves the issue and makes the test pass. Would this be a reasonable workaround or should I be calling some sort of function from move.c to update w_botline?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 13, 2022, 7:15:44 PM7/13/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

ba422bd Calculate botline from topline and height

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 13, 2022, 7:16:56 PM7/13/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

0cf47ff Calculate botline from topline and height

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jul 14, 2022, 12:09:00 PM7/14/22

to vim/vim, Subscribed

> I figured out `w_botline` is not the expected value here when running
> the test, hence the cursor is not set and the test fails. Is
> `w_botline` being outdated expected when running VimL functions?
>
> Exchanging `w_botline` for `w_topline + w_height` resolves the issue
> and makes the test pass. Would this be a reasonable workaround or
> should I be calling some sort of function from `move.c` to update

> `w_botline`?

No, when lines wrap then w_topline + w_height can be much higher than
the actual w_botline.

If it is really only for testing, a ":redraw" should work.
Otherwise you can use validate_botline(). This is an expensive function
though.

--
From "know your smileys":

=):-) Uncle Sam

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 14, 2022, 7:38:46 PM7/14/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

589752f Revert to botline and redraw to make test pass

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 14, 2022, 7:48:33 PM7/14/22

to vim/vim, Subscribed

No, when lines wrap then w_topline + w_height can be much higher than the actual w_botline.

Right, can confirm this change yielded the wrong outcome when wrapped lines are present.

If it is really only for testing, a ":redraw" should work.

I think it is, and indeed redraw makes the test pass.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 15, 2022, 2:28:50 AM7/15/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

ef8657f Restore test option defaults

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 15, 2022, 7:15:18 PM7/15/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

a82d04c Update docs

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 17, 2022, 8:38:55 PM7/17/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

74385b9 Scroll minimal amount proportional to scrolloff

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 18, 2022, 7:36:55 AM7/18/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

8cb9a3d Scroll minimal amount proportional to scrolloff

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 18, 2022, 8:15:32 PM7/18/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

f3ca47f Ensure scrolled to topline is valid

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 18, 2022, 8:24:07 PM7/18/22

to vim/vim, Subscribed

@luukvbaal commented on this pull request.

In src/window.c:

>  	        scroll_to_fraction(wp, prev_height);
+		curwin->w_valid &= ~VALID_TOPLINE;

Without this invalidation, it was possible to scroll to invalid cursor positions disobeying 'scrolloff'. I guess a consequence of setting w_fraction manually.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 18, 2022, 8:28:12 PM7/18/22

to vim/vim, Subscribed

I think the latest commit is a valid implementation of the proposed option. Requesting review I guess.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 18, 2022, 9:46:59 PM7/18/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

cbc0ce4 Incorrect use of curwin to wp

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 19, 2022, 7:12:56 AM7/19/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

bb0c5f1 Update docs

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 19, 2022, 8:07:05 AM7/19/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

4e01dc2 Make sure we scroll in new window

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 19, 2022, 6:14:52 PM7/19/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

ef17ad5 Fix indentation

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jul 23, 2022, 12:58:30 AM7/23/22

to vim/vim, Subscribed

Who has tried out this patch? Is it useful and does it work properly?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Null Chilly

unread,

Jul 23, 2022, 7:56:06 AM7/23/22

to vim/vim, Subscribed

I have tried it out, set splitscroll=2 helps stabilize your buffer content on window open/close event (In my case terminal toggling)

set splitscroll=1 also works correctly

Video preview:

https://user-images.githubusercontent.com/56817415/180603725-8fe33f94-150e-4bff-b251-83c0a64c6f92.mp4

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

bfrg

unread,

Jul 23, 2022, 8:07:54 AM7/23/22

to vim/vim, Subscribed

Instead of numbers, wouldn't it be better to use strings for the splitscroll option? It's hard to remember what which number does.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

bfrg

unread,

Jul 23, 2022, 8:26:24 AM7/23/22

to vim/vim, Subscribed

I have tried it out and it seems to work as intentional. Until now I had my own small script that does the same thing using autocommands with winsaveview() and winrestview(). Having a built-in option would be nice.

@luukvbaal There's one issue though. With set splitscroll=2 the buffer is still scrolled when the terminal window is resized such that it would hide the cursor. If there are multiple vertical split windows, only the currently focused window is scrolled.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

bfrg

unread,

Jul 23, 2022, 8:30:15 AM7/23/22

to vim/vim, Subscribed

It should probably also be mentioned somewhere that this option only works when splitbelow is set.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 23, 2022, 9:01:37 AM7/23/22

to vim/vim, Subscribed

Instead of numbers, wouldn't it be better to use strings for the splitscroll option?

Numbers seems to be the convention for similar options. See e.g. 'conceallevel' and 'laststatus'.

If there are multiple vertical split windows, only the currently focused window is scrolled.

I'm not sure this is an issue, the option claims to determine the scroll behavior when splitting, not when resizing. And when set splitscroll=2, to delay setting the cursor position setting the cursor to a valid position(botline) until you again focus the window. If you are actively resizing the splits, the currently active window will thus keep its cursor on botline(and scroll).
Would you expect all windows to scroll, or no windows to scroll including the currently focused window?

It should probably also be mentioned somewhere that this option only works when splitbelow is set.

Yeah fair. Or to improve the option to also "work" with 'nosplitbelow'(as in stabilize the window content, it currently just doesn't consider the option but you're right that different logic would be required to stabilize buffer content with 'nosplitbelow').

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 23, 2022, 8:20:07 PM7/23/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

b182fb5 Consider splitbelow vs nosplitbelow

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 23, 2022, 8:27:17 PM7/23/22

to vim/vim, Subscribed

Latest commit handles nosplitbelow where feasible. Stabilizing is possible when the cursor position is not hidden behind lower window but doesn't make sense when it would be.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 23, 2022, 8:34:29 PM7/23/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

cb398d1 Consider splitbelow vs nosplitbelow

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jul 24, 2022, 3:09:25 PM7/24/22

to vim/vim, Subscribed

> > Instead of numbers, wouldn't it be better to use strings for the
> > splitscroll option?
>
> Numbers seems to be the convention for similar options. See e.g.
> `'conceallevel'` and `'laststatus'`.

Those options were added long ago. These days we don't care so much for
the extra memory use, and care more for easy of use (since there are so
many options now). If we can come up with good, meaningful names that
would be preferred.

> > If there are multiple vertical split windows, only the currently
> > focused window is scrolled.
>
> I'm not sure this is an issue, the option claims to determine the
> scroll behavior when splitting, not when resizing. And when `set

> splitscroll=2`, to delay setting the cursor position setting the
> cursor to a valid position(`botline`) until you again focus the

> window. If you are actively resizing the splits, the currently active
> window will thus keep its cursor on botline(and scroll).
> Would you expect all windows to scroll, or no windows to scroll
> including the currently focused window?
>
> > It should probably also be mentioned somewhere that this option only
> > works when `splitbelow` is set.
>
> Yeah fair. Or to improve the option to also "work" with
> `'nosplitbelow'`(as in stabilize the window content, it currently just
> doesn't consider the option but you're right that different logic
> would be required to stabilize buffer content with `'nosplitbelow'`).

So when the 'splitscroll' option is non-zero (active) then 'splitbelow'
would be ignored? Or the other way around? That doesn't make sense.
If the new window is above the current window, it could still do the
same thing, right? It's only a matter of time until users ask for this.
Ah, it appears you already took care of it after this message.

--
hundred-and-one symptoms of being an internet addict:
110. You actually volunteer to become your employer's webmaster.

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 24, 2022, 3:42:36 PM7/24/22

to vim/vim, Subscribed

Those options were added long ago. These days we don't care so much for the extra memory use, and care more for easy of use (since there are so many options now). If we can come up with good, meaningful names that would be preferred.

I see, I guess I missed options like 'ambiwidth': https://github.com/vim/vim/blob/cb398d1a5b189261b32658e180d13081761b8d24/runtime/doc/options.txt#L743-L754?

Something like 'splitscroll' with these values then?

"relative": keep same relative cursor position(current default)
"stable": do not scroll if cursor is still visible
"force-stable": never scroll and set new cursor position when re-focusing window

So when the 'splitscroll' option is non-zero (active) then 'splitbelow' would be ignored? Or the other way around? That doesn't make sense. If the new window is above the current window, it could still do the same thing, right? It's only a matter of time until users ask for this. Ah, it appears you already took care of it after this message.

No nothing was ignored in earlier commits, window position would still honor 'splitbelow' but the logic required some mirroring to make sense for 'splitbelow' vs 'nosplitbelow'.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jul 24, 2022, 4:41:06 PM7/24/22

to vim/vim, Subscribed

> > Those options were added long ago. These days we don't care so much
> > for the extra memory use, and care more for easy of use (since there
> > are so many options now). If we can come up with good, meaningful
> > names that would be preferred.
>
> I see, I guess I missed options like `'ambiwidth'`: https://github.com/vim/vim/blob/cb398d1a5b189261b32658e180d13081761b8d24/runtime/doc/options.txt#L743-L754?
>
> Something like `'splitscroll'` with these values then?

> * "relative": keep same relative cursor position(current default)
> * "stable": do not scroll if cursor is still visible
> * "force-stable": never scroll and set new cursor position when re-focusing window

Reading the explanation gives a hint about what to call them:
how about: "normal", "noscroll" and "neverscroll"?
"stable" doesn't really give a clue.

--
"New York, the city that never sleeps". "There is so much noise?"

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

bfrg

unread,

Jul 25, 2022, 6:59:56 AM7/25/22

to vim/vim, Subscribed

Would you expect all windows to scroll in this case, or no windows at all, including the currently focused window?

I think the current behavior is inconsistent. The inactive windows are not scrolled but the currently focused one is. I would have expected all windows to stay "stable" when the Vim terminal window is resized.

And there's another inconsistency. Let's say you have two vertical splits and then you run :botright copen. While in the quickfix window, run :resize +5. You can run the command multiple times and none of the vertical splits will be scrolled (assuming set splitscroll=2). I would have assumed the same behavior when the entire screen is resized (think of a quick tmux split-window, or quickly opening a new terminal window with a tiling window manager).

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

bfrg

unread,

Jul 25, 2022, 8:45:23 AM7/25/22

to vim/vim, Subscribed

@luukvbaal There's another case when the currently focused window is scrolled but the other split windows are kept stable.

Open two vertical splits, place the cursor at the bottom in each window. Then open the command-line window with q:, and the close it with :q. When the command-line window is opened, the windows are not scrolled, but when it's closed, the last focused window is scrolled.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Jul 30, 2022, 3:14:22 PM7/30/22

to vim/vim, Subscribed

Reading the explanation gives a hint about what to call them: how about: "normal", "noscroll" and "neverscroll"?

Yeah sure, sounds good to me. I have a commit ready implementing the change to stringopt.

Sorry for not getting back to some of the replies here. I think the option implementation requires some further consideration. It works for the simple case splitting a single window into two but I'm not sure isolating the change to win_new_height() is sufficient. I think we might require some of the logic in win_split_ins() handling all the edge cases. Will have to look at it again. Consider draft for now.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 8, 2022, 7:36:53 PM8/8/22

to vim/vim, Subscribed

I reworked the option to truly obey the description in all cases (I think). Any and all opened splits will maintain their current scroll position regardless of how they were opened (topleft/belowright/(no)splitbelow etc.

In the process I reverted back to a boolean option and got rid of the non-forcing noscroll option, only keeping the (now more comprehensive) neverscroll. Always setting the cursor position instead of scrolling. I'm not sure adding back the noscroll option will be worth the hassle/code.

Another round of testing would be appreciated. Tests still need updating.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 8, 2022, 7:57:52 PM8/8/22

to vim/vim, Subscribed

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 8, 2022, 8:09:16 PM8/8/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

fbf9180 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 8, 2022, 8:23:26 PM8/8/22

to vim/vim, Subscribed

tabline/winbar could use handling as well, not sure if feasible or worth it.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 8, 2022, 9:03:44 PM8/8/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

8959a03 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 8, 2022, 9:31:03 PM8/8/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

fcf311c Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 8, 2022, 11:36:17 PM8/8/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

1aea71e Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 6:50:05 AM8/9/22

to vim/vim, Subscribed

RE the failing tests: right, the topfrp argument is a remnant of when I tried to reduce the handling of unchanged windows by only passing the frame where the window heights have changed. Couldn't get it working right away properly, not sure if it's still possible but maybe the current check is sufficient for performance considerations and we can get rid of the frame arg:

https://github.com/vim/vim/blob/1aea71e8c3800409fbce66850a6bfd60c1bf97f0/src/window.c#L6371-L6373

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 6:53:58 AM8/9/22

to vim/vim, Subscribed

I wasn't sure if it's always possible to know the frame(s) that contain changed windows and pass it to the scroll correct function from where it's called. I think looping over all the windows in to be sure is fine and unnecessary work is avoided by the prev_height check.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 10:52:52 AM8/9/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

a2018cd Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 10:58:52 AM8/9/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

1139761 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 11:00:06 AM8/9/22

to vim/vim, Subscribed

@luukvbaal commented on this pull request.

In src/window.c:

> @@ -1327,6 +1333,11 @@ win_split_ins(
 	msg_col = 0;	// put position back at start of line
     }
 
+    // If we have there is a winbar, win_equal invalidates w_botline
+    // before we get to spsc_correct_scroll (why only with winbar?).
+    if (!p_spsc && WINBAR_HEIGHT(curwin))

@brammool with the latest commit we also avoid scrolling in all cases when a winbar is present. Without this check w_botline was invalidated due to some recursive calls to win_new_width() in equal_win(), before we get to spsc_correct_scroll(). Resulting in scrolling in curwin(actually prevwin after win_enter_ext(wp).

Would a check like this be okay? It's not really checking against the root cause of what causes scrolling but it seems to work and I don't see any side effects.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 12:10:12 PM8/9/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

37ff81d Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 12:11:07 PM8/9/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

bf6b035 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Aug 9, 2022, 2:28:13 PM8/9/22

to vim/vim, Subscribed

> @luukvbaal commented on this pull request.
>

> > @@ -1327,6 +1333,11 @@ win_split_ins(
> msg_col = 0; // put position back at start of line
> }
>
> + // If we have there is a winbar, win_equal invalidates w_botline
> + // before we get to spsc_correct_scroll (why only with winbar?).
> + if (!p_spsc && WINBAR_HEIGHT(curwin))
>

> @brammool with the latest commit we also avoid scrolling in all cases when a winbar is present. Without this check `w_botline` was invalidated due to some recursive calls to `win_new_width()` in `equal_win()`, before we get to `spsc_correct_scroll()`. Resulting in scrolling in `curwin`(actually `prevwin` after `win_enter_ext(wp)`.

>
> Would a check like this be okay? It's not really checking against the root cause of what causes scrolling but it seems to work and I don't see any side effects.

I'm not quite sure what your strategy is. I thought that when
'splitscroll' is off then in every window w_topline remains unchanged.
If the window heigh changes, this means w_botline will become invalid.
Then the cursor may have to be moved to keep it in the visible text.
w_botline will be updated automatically, although you may want to do it
before deciding where to put the cursor.
I have no idea why the window bar matters in any of this.

--
Bravely bold Sir Robin, rode forth from Camelot,
He was not afraid to die, Oh Brave Sir Robin,
He was not at all afraid to be killed in nasty ways
Brave, brave, brave, brave Sir Robin.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 2:50:34 PM8/9/22

to vim/vim, Subscribed

The strategy is to keep all lines on the same actual terminal line, updating the cursor to a valid position rather then scrolling when necessary. To do this, indeed topline remains unchanged a window is reduced in size from below(botline shifts upward).

However, when a window is reduced in size from above(i.e. when winrow != prev_winrow), to keep the window content "stable", we have to update topline instead. To do this, I am setting the cursor line to where the new botline would have been, followed by a scroll_to_fraction() with fraction set to FRACTION_MULT, such that this cursor position will be the new botline.

This botline value depends on the value of laststatus, the number of windows in a frame/tabpage, and the winbar height. I think I covered all possible cases now but I'm not quite sure why the recursive calls to win_new_width() only happen when a winbar is open. It feels like I'm working around the problem but if it works it works.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Aug 9, 2022, 4:44:46 PM8/9/22

to vim/vim, Subscribed

> The strategy is to keep all lines on the same actual terminal line,
> updating the cursor to a valid position rather then scrolling when
> necessary. To do this, indeed `topline` remains unchanged a window is

> reduced in size from below(`botline` shifts upward).

>
> However, when a window is reduced in size from above(i.e. when

> `winrow` != `prev_winrow`), to keep the window content "stable", we

> have to update `topline` instead. To do this, I am setting the cursor
> line to where the new `botline` would have been, followed by a

> `scroll_to_fraction()` with fraction set to `FRACTION_MULT`, such that
> this cursor position will be the new `botline`.
>
> This `botline` value depends on the value of `laststatus`, the number
> of windows in a `frame/tabpage`, and the `winbar` height. I think I

> covered all possible cases now but I'm not quite sure why the
> recursive calls to `win_new_width()` only happen when a winbar is
> open. It feels like I'm working around the problem but if it works it
> works.

Hmm, I think what you are trying to do is not 100% possible.
The topline can only be the start of a buffer line, thus when this line
wraps it occupies two screen lines. If the window moves down one screen
line, then either you keep topline, in which case the window contents
scrolls down one screen line, or you increment topline, in which case
the window contents scrolls up one screen line. See what I mean?

There is a todo item somewhere to have the first line possible start
halfway the line. That would have to be implemented first. The reason
it's not done yet is that it will require a lot of work to get right.

--
Error:015 - Unable to exit Windows. Try the door.

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 4:50:29 PM8/9/22

to vim/vim, Subscribed

Hmm, I think what you are trying to do is not 100% possible.
The topline can only be the start of a buffer line, thus when this line wraps it occupies two screen lines.

Yeah true, I noticed this during testing. I saw it as an acceptable loss for now, I use nowrap my self and it will still lead to less scrolling, even when lines are wrapped.

There is a todo item somewhere to have the first line possible start halfway the line. That would have to be implemented first. The reason it's not done yet is that it will require a lot of work to get right.

I can imagine this will be tricky.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 7:53:22 PM8/9/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

b21abb1 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 8:09:38 PM8/9/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

1a18008 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 9, 2022, 8:38:33 PM8/9/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

17e99e5 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 8:25:15 AM8/10/22

to vim/vim, Subscribed

@barmmool How would I go about adding topfill lines to a window? I'm trying to stabilize one (final hopefully) case where the curwin has a winbar and is split above. The winbar will move to the with the window to the lower split, leaving more available toplines for the upper split.
I can account for this by scrolling up, but when w_topline < WINBAR_HEIGHT(curwin), topfill lines would have to be added instead.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 8:28:38 AM8/10/22

to vim/vim, Subscribed

See https://asciinema.org/a/zKuzBLQttMYGsjvnx7Yi6DTwL for visualization.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Aug 10, 2022, 8:48:57 AM8/10/22

to vim/vim, Subscribed

> @barmmool How would I go about adding topfill lines to a window? I'm trying to stabilize one (final hopefully) case where the curwin has a winbar and is split above. The winbar will move to the with the window to the lower split, leaving more available toplines for the upper split.

> I can account for this by scrolling up, but when `w_topline < WINBAR_HEIGHT(curwin)`, topfill lines would have to be added instead.

filler lines are only for when using diffmode when two windows are to be
kept in sync. Their use is very complicated, using them also in another
situation is not a good idea.
Implementing the other solution, having the first line start with some
offset, is much more useful. Also complicated, but there is a reason to
spend time on it.

--
Facepalm statement #1: "I'm going to New York tomorrow, hopefully I have time
to visit the White House"

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 8:55:43 AM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

a31dfd8 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 9:03:03 AM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

3226ee2 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 9:06:54 AM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

d18fb76 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 9:12:53 AM8/10/22

to vim/vim, Subscribed

I see, thanks. I think this is it for now then. Still waiting for some feedback on whether the normal/noscroll/neverscroll option is deemed necessary, also over at the neovim PR.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 9:36:41 AM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

a4ea841 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 9:49:56 AM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

294a6ab Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 10:03:07 AM8/10/22

to vim/vim, Subscribed

Not sure why the added test fails on appveyor with gvim, can't seem to replicate it failing.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

bfrg

unread,

Aug 10, 2022, 10:49:46 AM8/10/22

to vim/vim, Subscribed

Is it possible to add the old cursor position to the jump list before it is changed? Does it even make sense?

Just a thought: imagine, I carefully placed the cursor somewhere in the buffer, then open a new split, and it happens that the cursor is moved up to avoid scrolling the window. If I focus the previous window before I opened the split, the cursor will be on a different line. Someone might need the old position, in that case my first thought would be to hit <C-o> to jump back to the previous buffer position. But this doesn't work at the moment.

I tested the latest version. There are still some cases when the window is scrolled.

Open two vertical splits, place the cursor at the bottom in each window. Then open the command-line window with q:. When the command-line window is opened, the last window is scrolled.

With set nosplitscroll, when a vertical split is opened with <c-w>v, the cursor is not at the same position in the split. This is unexpected. Why is the cursor moved in the new vertical split? I think it should stay at the old position, since everything is copied from the old window.

This is illustrated in the following video. Before I open the vertical split, the cursor is at the very bottom of the buffer on the word "Atari". By default the old cursor position is copied when a new split is opened. But when I hit <c-w>v, the cursor is moved 5 lines above (below the line "OS/2 support...").

https://user-images.githubusercontent.com/6266600/183931234-cd4e3197-aee8-4e5d-a3d3-a305cd6b410a.mp4

It looks like that for vertical splits, it is never possible to keep the cursor at the very bottom of the window. Open two vertical splits, place the cursor at the bottom and then hit <c-w>p. The cursor is not at the old position anymore. Even if no windows have been opened.

Note: for consistency, there should probably also be help tags for nosplitscroll and nospsc.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 11:38:51 AM8/10/22

to vim/vim, Subscribed

Is it possible to add the old cursor position to the jump list before it is changed? Does it even make sense?

Yeah my plugin did this as well. It does make sense I guess although I can't say I ever used it. Would have to figure out how to populate the jumplist.

Thanks for testing, I'll look into the problems you mentioned. You're right that vertical splits should be skipped altogether. I had this in previous versions but got lost somewhere along the way. Although I wonder if it is always enough to know that a vertical split was spawned. I'm not familiar with all the possible ways splits can be opened. Can there ever be opened a vertical split where other windows in the tab might change in height? That would complicate things.

The q: one is interesting, not sure why it isn't handled currently. Is it not a regular window? I'll check it out.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 1:47:31 PM8/10/22

to vim/vim, Push

@luukvbaal pushed 2 commits.

b4628b4 Do not try to correct vertical split
a20c325 Do not scroll when in cmdline mode

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 4:31:26 PM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

77c8b5d Set jumplist when adjusting cursor position

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 4:41:45 PM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

7f3a496 Set jumplist when adjusting cursor position

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 4:54:45 PM8/10/22

to vim/vim, Subscribed

@bfrg I think I addressed everything you mentioned, thanks again for testing it out.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 5:08:39 PM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

c5c52a8 Set jumplist when adjusting cursor position

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 5:17:53 PM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

2e40f5a Update options.txt

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 5:28:56 PM8/10/22

to vim/vim, Subscribed

Alright, I'm happy with how this looks and works now. I would consider it mergeable and would put it up for review @brammool but I haven't had any feedback yet from neovim side on the omission of the noscroll option(or here for that matter, but there were some opinions shared on the option earlier and it originated over at the neovim PR). The addition of the jumplist entry with the old cursor position makes it even more obsolete imo.

The failing test on appveyor with gvim still requires fixing I guess but I haven't been able to reproduce it yet. It seems to be running the test on windows, perhaps I can reproduce it there.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 5:39:29 PM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

1396528 Fix indentation

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 5:43:05 PM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

32e8d53 Fix indentation

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

bfrg

unread,

Aug 10, 2022, 6:17:20 PM8/10/22

to vim/vim, Subscribed

For vertical splits, the cursor is still moved even though it's not necessary.

To reproduce, place the cursor on the very last line of the window and the open a new vertical split with <c-w>v. In the new window, the cursor remains in the same line as in the previous window, but when I jump back with <c-w>p, the cursor has been moved up. If I press <c-w>p again, it has been moved in the other window as well. The cursors should remain at their previous positions since no window was scrolled. You can try to move the cursor to the lowest line in each window and then focus the previous window. The cursor will be moved up again. It looks like the amount it is moved up depends on scrolloff which is set to 5 by default.

Pressing <c-o> works as expected 👍 .

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 6:37:48 PM8/10/22

to vim/vim, Subscribed

To reproduce, place the cursor on the very last line of the window and the open a new vertical

Oh right, though this is only true and "not necessary" when the last line of the window is also the last line of the buffer/file. I can't reproduce it on any arbitrary position in the buffer when placing the the cursor on the last line(also not possible when scrolloff is set). Is that what you mean, or are you seeing this without scrolloff set/not on the last line of the buffer?

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 6:55:50 PM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

71660ad Do not set cursor to so at top/bottom of buffer

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 10, 2022, 6:56:55 PM8/10/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

5ce113f Do not set cursor to so at top/bottom of buffer

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 11, 2022, 7:35:32 AM8/11/22

to vim/vim, Subscribed

@brammool I would like to do some refactoring and look into the failing test(seems it fails on gvim although I can't reproduce), perhaps hold off on review if you were planning to.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 11, 2022, 11:44:53 AM8/11/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

21474e1 Cleanup

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 11, 2022, 11:57:13 AM8/11/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

67a9d16 Cleanup

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 11, 2022, 3:04:19 PM8/11/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

53c007e Update test

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 11, 2022, 4:45:56 PM8/11/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

ede5435 Cleanup

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 11, 2022, 5:06:29 PM8/11/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

32c6a5a Fix scrolling at end of buffer

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 11, 2022, 5:08:11 PM8/11/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

61d79e9 Fix scrolling at end of buffer

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 11, 2022, 5:16:49 PM8/11/22

to vim/vim, Subscribed

Done with this for now. There is still the winbar edgecase(scroll offset by winbar height) when opening a vertical split or horizontal split above the winbar but it's not a merge blocker imo. Won't have time to look at it until later this month.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 11, 2022, 9:06:38 PM8/11/22

to vim/vim, Push

@luukvbaal pushed 2 commits.

02a1c64 Use win_count()
571cabe Avoid scrolling with tabline and test it

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Aug 12, 2022, 7:24:41 AM8/12/22

to vim/vim, Subscribed

Can some people try this out and give feedback?

spsc_correct_cursor() and spsc_correct_scroll() are declared static but the function are not.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 12, 2022, 8:11:11 AM8/12/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

31d4840 spsc functions are static

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 12, 2022, 10:27:55 PM8/12/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

965c7d9 Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 13, 2022, 7:51:09 AM8/13/22

to vim/vim, Push

@luukvbaal pushed 1 commit.

ace636e Add new option splitscroll to avoid scrolling

—
View it on GitHub or unsubscribe.

You are receiving this because you are subscribed to this thread.

Ben Jackson

unread,

Aug 14, 2022, 6:14:04 AM8/14/22

to vim/vim, Subscribed

I gave this a quick spin. It seems to work reasonably well and the results were unsurprising, which has to be the goal.

However, I was sort of confused by the result of :1spl I was expecting the 1-line split to cover the first line in the buffer in the same way that in :split or rightbelow 1split we sort of "steal" the screen lines at the bottom of the buffer.

here's some playing including the result of a number of 1spl actions: https://asciinema.org/a/oA68f6K9CKHRV04HMfLYiZe0p

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

luukvbaal

unread,

Aug 14, 2022, 6:23:20 AM8/14/22

to vim/vim, Subscribed

Yes, I would agree the result of :1split is surprising. It seems to work as expected for 2:split. I doubt many people ever run :1split but I'll look into it thanks.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

[vim/vim] Add new option splitscroll to avoid scrolling (PR #10682)

luukvbaal

You can view, comment on, or merge this pull request online at:

Commit Summary

File Changes

Patch Links:

codecov[bot]

Codecov Report

Bram Moolenaar

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

Bram Moolenaar

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

Bram Moolenaar

Null Chilly

bfrg

bfrg

bfrg

luukvbaal

luukvbaal

luukvbaal

luukvbaal

Bram Moolenaar

luukvbaal

Bram Moolenaar

bfrg

bfrg

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

Bram Moolenaar

luukvbaal

Bram Moolenaar

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

Bram Moolenaar

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

luukvbaal

bfrg

luukvbaal

luukvbaal

luukvbaal