Ctrl-D does not work when scrolloff is a big value

[dcordb]

Ctrl-D does not work right if scrolloff is big, for example scrolloff=999. Steps to reproduce are:

1. Execute set scrolloff=999.
2. Press Ctrl-D to scroll down.
3. You should see that smooth scrolling is not applied.

[dcordb]

I have to say that it somewhat works for small values, for example scrolloff=25. But it scrolls more than it should. To reproduce:

1. let's prepare a file of 250 lines
2. set scrolloff=25
3. place the cursor at line 1 and scroll down (half a screen ie. with Ctrl-D) from it
4. the cursor should land at line 115, which is a lot.

If I deactivate neoscroll and run the same steps then the cursor lands on line 46.

All this happens with the following configuration of neoscroll:

require('neoscroll').setup({
  hide_cursor = false
})

[karb94]

Yes, at the moment Neoscroll assumes that the scrolloff value is a number between 0 and half the number of line in the current window. I never considered the case when a high scrolloff value is set so that the cursor is always at the middle so I would expect quite a few issues with such settings. I'm going to be away for a week but I'll try to come up with a fix when I get back.

[karb94]

@dcordb could you check if everything works as expected? If not let me know and I'll reopen the issue. I wouldn't be surprised if I there were some edge cases that I overlooked.

[dcordb]

I tested it now, it works. But when I scroll from the first line (down), or from the last line (up), it appears that the cursor first skips some lines and then starts to smooth scrolling, ie. it looks like the cursor jumps first to some line and then start smooth scrolling from it.

[karb94]

If I understand you correctly that's just how neovim works. Disable Neoscroll and set scrolloff to some value. If you now go to the first line and try to move the window (i.e. press c-e) the cursor will automatically jump to the window line equal to scrolloff. Keep in mind that Neoscroll is meant to scroll your window. It doesn't to scroll the cursor on its own unless the window can't be scrolled anymore and your neoscroll settings have cursor_scrolls_alone enabled.

Could you try to describe your expected behaviour? I presume you are expecting first the cursor to scroll to it's scrolloff value smoothly and then scroll your window as normal?

[dcordb]

@karb94 yes you've explained quite well.

Could you try to describe your expected behaviour? I presume you are expecting first the cursor to scroll to it's scrolloff value smoothly and then scroll your window as normal?

Yes exactly this I what I would like, but for what you said maybe it's not possible.

Btw, I didn't say it but thanks for making this project! :ok_hand:

[karb94]

Yes exactly this I what I would like, but for what you said maybe it's not possible.

Just to be clear, it is possible. I just don't know if the majority of the people would like to have that extra "delay" when scrolling from the top or bottom as it might feel inconsistent with the rest of the scrolling animations around the file.

If I see that someone else asks for this feature I will add it as an option but I think for now I will leave it as it is because it is not as trivial to implement as one might think.

PS: thank you for your kind words :smiley:

[cooperuser]

I think this is where I jump in and say I 🖐️ am that someone else and would much appreciate this feature!

I've been using vim-smoothie for a few years or so, but I'm now attempting the switch to neoscroll.nvim. I didn't realize that this described feature is what I preferred until I noticed it wasn't there anymore upon switching. If I am not mistaken, plugins like vim-smoothie work by actually moving the cursor instead of the viewport, and let vim's internal scrolloff feature handle itself. From what I've seen, this plugin has much better performance, which might be due to the switch away from that...

I hope that this could be added somewhat easily, if I have time I might try implementing it myself but we'll see. Thanks! ❤️

[cooperuser]

@karb94 @dcordb

(bump to make sure this gets seen; I'm not sure how notifications work on closed issues.)

[karb94]

@dcordb Fair enough. I'll creat a new issue for this feature request. I don't have much time in my hands right now but I promise this will be implemented eventually. I just tried vim-smoothie and the delay introduced by moving the cursor to the scrolloff one line at a time is not that noticable so this probably will end up being the default behaviour.

Just to clarify, the improved performance has nothing to do with this. Fundamentally all scrolling plugins are doing the same. They use C-e/C-y and j/k in quick succession to move the cursor/buffer accordingly. The performance comes from how you perform all the calculations behind the scenes to achieve the desired behaviour without wasting resources and by the simple fact that Lua performes these calculations faster than VimScript. The main limitation now is neovim's main loop and how fast it is able to draw highlights (which has been greatly improved by treesitter).

[karb94]

Created #52 for this feature request

[cooperuser]

Perfect! And thank you for the clarification!