When scrolling using the trackpad on my 2017 Macbook pro, the sensitivity is so high that the only thing i can reliably do is going to the start or end of the file.
Going slowly seems to make it even worse, i can scroll through a 500-line file with about 2cm of movement.
Other text editors on my system do not have this problem.
Other electron apps on my system do not have this problem.
I have the same issue here.
Possibly duplicate of https://github.com/onivim/oni/issues/405
The scrolling motion can only happen in full line height steps at the moment.
This could probably be mitigated by configuring the threshold amount of scroll needed to advance one row, but the ideal solution would be smooth scrolling outside the vim grid limitations.
If there's smooth scrolling with bounce back then it'd be fantastic!
I might sound crazy, but I'd switch editor for that bounce back
This is not a dupe of #405, but a different issue. I'm experiencing the same; on my MacBook it's practically speaking impossible to scroll accurately with the touchpad. At the level where the scrolling action is detected, the view already jumps about 20 lines. An amount of scrolling that in a browser window moves the view about one line moves the view 50-100 lines in Oni.
I too am having the same issue. The screen runs so rapidly that it makes scrolling with the trackpad somewhat unfeasible.
This seems like a really bad issue 馃槮 I wish I had a Macbook Pro to reproduce it on! Smooth scrolling is a ways out, but for the time being, it seems like we should be able to throttle the scroll motion and at least behave reasonably.
We're likely not picking up the scroll delta correctly here in response to the trackpad, or perhaps we need to account for some other values.
If someone has a Macbook and can reproduce this, this code would be the place to look:
https://github.com/onivim/oni/blob/c601fad812ba14b515ab3d8604358e3eee531b87/browser/src/Input/Mouse.ts#L36
Specifically, it'd be helpful to log out the evt.deltaY here - what are the values we're getting?
if (evt.deltaY) {
if (evt.deltaY < 0) {
scrollcmdY += `ScrollWheelUp>`
} else {
scrollcmdY += `ScrollWheelDown>`
}
this.emit("mouse", scrollcmdY + `<${line},${column}>`)
}
Some additional info from Discord, and troubleshooting with this codepen: https://codepen.io/anon/pen/WzgwOE
My values, on Windows w/ mouse:
https://gist.github.com/bryphe/43caa81bbec16d90d7b47f084014774b
@CrossR 's values, on Surface:
https://gist.github.com/CrossR/a9b8b973a53f66ba78f53cd8c47fc547
And a few interesting things looking at the code... we don't actually take into account the delta at all, or the delta mode. Because of that, this code would be very sensitive to the _frequency_ of events, and it's possible that the macbook trackpad has a higher frequency of pixel delta events.
We should switch this to use the <ScrollWheelUp> and <ScrollWheelDown> events which scroll a single line (taking into account the delta / deltaMode). A first implementation could simply round the number of lines in response to a delta event - it won't be perfect for small scrolls, but it would work reasonably.
A next iteration could implement some form of 'peaking' - transform the canvas by the remainder of the leftover scroll. This would feel a bit nicer, as it would be a step towards smooth scrolling...
And then of course, would like to get to _actual_ smooth scrolling 馃槃
Thanks @aquova for testing out the codepen on the touchpad! More details from discord:
I think this explains it. The code wasn't taking the delta into account at all... and just would scroll a line in response to scroll events coming in.
On Windows, it was kind of okay, because the delta is a lot higher per-event, so lower frequency scroll events are emitted - and our code works OK.
But on the MacBook touchpad, the scroll events only cover a few pixels, and thus that are a lot more... and because the code right now scrolls a line in response to each event, you get a lot of lines scrolled with a small gesture!
Bit off topic, but you can also scroll the Vim-way via the keyboard:
Ctrl-y Moves screen up one line Ctrl-e Moves screen down one line Ctrl-u Moves cursor & screen up 陆 page Ctrl-d Moves cursor & screen down 陆 pageMore here : https://stackoverflow.com/questions/3458689/how-to-move-screen-without-moving-cursor-in-vim
Don't forget to enable key repeat, as per the wiki. (I had to restart the Mac to get it activated)
And of course you should have already set _Key Repeat_ and _Delay Until Repeat_ to the max in _Keyboard_ in the Mac OS _System Prefences_ ! 馃悋
Just a data point: on my MX Master each scroll event jumps 3 lines, works good for me.
hey qq, is this fix included in v0.3.2? thanks!
Hi @jaanauati - unfortunately this is not in the v0.3.2 build - came in a few days after.
On linux (with the pre-built binaries from 0.3.6) mouse scrolling is very slow, some mouse events seem to be ignored. Feels very sluggish, almost unusable.
Yes, same for osx, scrolling feels weird.
I'm wondering if the reports of scrolling issues are a regression as a result of the upgrade to nvim 3.0. Also, it's not a solution to the issue, but I would encourage everyone with scrolling issues to explore using the movement keys outlined by bfulop previously in this thread and avoiding the mouse. It's the vim way, after all. 馃槃
and avoiding the mouse. It's the vim way, after all
The vim way is terminal, so maybe we should all just stop using gui? ;)
hey @bryphe!!, scrolling is still working oddly for me, as stated before, it seems like the pull request linked to this ticket made things even worse... been poking with the minified file and it seems like setting a value like 10 here https://github.com/onivim/oni/blob/master/browser/src/Input/Mouse.ts#L5 improves things a lot for me (high sierra // 10.13.6 (17G65)) getting a much more fluid scrolling.
Here my pull request with the quick fix: https://github.com/onivim/oni/pull/2551
Thanks.
Most helpful comment
Possibly duplicate of https://github.com/onivim/oni/issues/405
The scrolling motion can only happen in full line height steps at the moment.
This could probably be mitigated by configuring the threshold amount of scroll needed to advance one row, but the ideal solution would be smooth scrolling outside the vim grid limitations.