Can we move away from emulating neovim behavior for scrolling?

[Bretley]

I think the Grid implementation is a bit bad, and I don't mean that from an implementation perspective. The scrolling in oni, in my opinion, isn't worse than neovim. At least for me, it feels about the same. If we could somehow render a large (basically render ahead to a certain arbitrary point where it becomes not worth the benefit) portion of the Grid implementation but make it all on an actually scrollable page, we could just send a cursor position back to Neovim instead of sending scroll events. The issue with scroll events is that (especially on OSX) on modern laptops that have fast/inertia scrolling, it's just firing off too many times in a second.

[bryphe]

Yep, good suggestion. The scrolling behavior in Oni doesn't really fit with what you'd expect from a modern modal editor.

There were some related ideas that @trusktr brought up in #88 - we could implement smooth scrolling if we render a larger area. This would be very difficult currently until we implement #362 , which externalizes the window / buffer management. The problem today is that if you attempted to attach Neovim to a larger window size, that would apply to all splits and cause problems (one being that the command line and statusbar would be offscreen). Once the window management is externalized, though, we'd have the flexibility to implement this.

I put this in milestone 0.4, which is going to be heavily focused on the UI modernization aspects of Oni. Having scroll behave as you expect is an important goal 😄

One thing I'm not sure about is if we would need any changes to Neovim core to support this scenario, so that will be a piece of this investigation.

[justinmk]

In nvim, externalization of tabline was just merged. Looking for feedback there, which will inform the approach for statusline, cmdline and wildmenu.

There are PRs open for those already, and work will accelerate now that we have the API contract clarified (:help api-contract). But we do need feedback from UI authors.

[Bretley]

I was writing just a little bit of the vim script to get the necessary data, would you care to point me to which methods were just added?

[bryphe]

Nice, thanks @justinmk ! Look forward to checking this out.

[manu-unter]

I agree that virtualizing the actual scroll position would be a rather complex task. Especially thinking about customizability with status bars inside the neovim window and the cursor-triggered scrolling, I Think we might end up creating more problems than we solve. This is a topic we should think through thoroughly.

Maybe we could find a middle ground: keep the neovim viewport like it is now but don't directly pass the scroll events through but rather accumulate them and only scroll an actual neovim row each time the scrolling distance surpasses the line height?
I'm pretty sure that people used to working in vim have no interest in being able to scroll half a line in height and people used to Pixel-based scrolling won't miss it if we get it to work smoothly. What do you think?

Maybe even we could try this as an intermediate step and try it out before changing the complete wrapping of the neovim viewport?

[Bretley]

I think it is possible to have smooth scrolling that only ever lands perfectly on a vim line

…

________________________________ From: Manuel Hornung <notifications@github.com> Sent: Friday, May 4, 2018 11:39:28 AM To: onivim/oni Cc: Barkley, Bret; Author Subject: Re: [onivim/oni] Can we move away from emulating neovim behavior for scrolling? (#405) I agree that virtualizing the actual scroll position would be a rather complex task. Especially thinking about customizability with status bars inside the neovim window and the cursor-triggered scrolling, I Think we might end up creating more problems than we solve. This is a topic we should think through thoroughly. Maybe we could find a middle ground: keep the neovim viewport like it is now but don't directly pass the scroll events through but rather accumulate them and only scroll an actual neovim row each time the scrolling distance surpasses the line height? I'm pretty sure that people used to working in vim have no interest in being able to scroll half a line in height and people used to Pixel-based scrolling won't miss it if we get it to work smoothly. What do you think? Maybe even we could try this as an intermediate step and try it out before changing the complete wrapping of the neovim viewport? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fonivim%2Foni%2Fissues%2F405%23issuecomment-386640539&data=01%7C01%7Cbrb171%40pitt.edu%7C1913a442a9a6402061b208d5b1d539a6%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=G0rDtARLMw4BQluubafEaAM%2BfoYeKKvedQzyW%2F1TJsk%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAICBCUxz3wgd3nftEM1yw7o6d3n8mJZKks5tvHYwgaJpZM4NIvc-&data=01%7C01%7Cbrb171%40pitt.edu%7C1913a442a9a6402061b208d5b1d539a6%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=fRkIU1%2FdvO0zLf5uYJNwM6Jhw7OqEZ0IwdWdY8KXvF8%3D&reserved=0>.

[bryphe]

Maybe we could find a middle ground: keep the neovim viewport like it is now but don't directly pass the scroll events through but rather accumulate them and only scroll an actual neovim row each time the scrolling distance surpasses the line height?
I'm pretty sure that people used to working in vim have no interest in being able to scroll half a line in height and people used to Pixel-based scrolling won't miss it if we get it to work smoothly. What do you think?

Ya, I think this is a great compromise. Would be definitely worth trying this out first before completely revamping our render strategy 😄

What I was curious about with this strategy is that, if I start to slowly scroll up/down with the mouse cursor - would we just show an empty line that would 'snap in' once the actual neovim scroll was come in? It'd be interesting to try test out that flow and see if it'd be confusing to the user - I guess it depends on the threshold in which we register the neovim scroll. But I think this could definitely be reasonable.

I view the mini-map as being an interesting challenge for our rendering strategy (#1040) - that would need to be decoupled from the neovim render strategy by necessity (because it's viewport will be different than anything we'd get from the terminal strategy). That would sort of be a good PoC, too, to see the challenges with wrapping the Neovim viewport (without the complexity of adapting our current editor surface to it, too).

[Piping]

What about show pixel-wise scroll when scrolling with touchpad for example? and send cursor position when scroll stops?
One example is how vim-mode plugin for vscode support smooth scrolling behavior while still be able to locate the cursor after scroll stops

[benjie]

If we do replace Neovim scrolling we'll need to be careful to not lose functionality such as :set scrolloff=5 / etc. Re-implementing this functionality in Oni seems non-optimal.

[Piping]

@benjie scrolloff is annoying when using shortcuts like H. For actual scrolling, it should not be a concerned in GUI.

[benjie]

Though that may be true for you, I don't find combining `H` / `L` with `scrolloff` to be annoying so I don't think that's a universal concern. (Click to expand more thoughts on this.)

I don't want to fill this issue up with irrelevant commentary, so I've hidden this inside a details tag.

scrolloff is very handy when you're doing things like searching the document for text and wanting to view a few lines of the context of each of the matches, similar to the -C context option you can use with grep when searching files on the command line. I frequently set scrolloff to 3 or 5 when searching/find and replacing, or even when executing macros selectively. Most of the time I have it set to 0 or 1 though.