luukvbaal

> In terms of how we do it, I think we should just add 'splitoptions', even if it only contains one option. > > For that reason I don't think...

> I'm not sure what is required to update w_botline at this point (and if what is required will be worth it for this edge case). ~A `redraw_asap()` seems to...

Vim is requesting user experience with the patch: https://github.com/vim/vim/pull/10682#issuecomment-1193060554.

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...

I was thinking tests could go in `testdir/test_window_cmd.vim` looking something like: ```vim func Test_splitscroll_with_splits() set splitbelow set scrolloff=0 set splitscroll=1 call setline(1, range(1,256)) norm M2k "move cursor to line above...

> 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...

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

> 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'`. >...

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.

> 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...