-
Notifications
You must be signed in to change notification settings - Fork 300
#4332 - Fix bug with 'onScrolled' event not firing in all cases #2143
Conversation
@@ -760,6 +765,7 @@ export class NeovimInstance extends EventEmitter implements INeovimInstance { | |||
break | |||
case "scroll": | |||
this.emit("action", Actions.scroll(a[0][0])) | |||
this._dispatchScrollEvent() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bryphe ah this was the line I was referring to which I though represented a scroll event from neovim, that was the what I was logging out which was providing a more accurate response to scrolling didnt realise it was from the redraw event
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha ya, I think the "bug" is that we weren't using it for our onScroll
event 😄 So we were missing out on this info, which is the most reliable way to check for scroll events when the cursor doesn't move (it misses large scroll events, like G
on a long file)
if (this._isDisposed) { | ||
return | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was also logging here so I thought this bit being put into the the event loop rather than running synchronously was where things were going missing since if by some quirk of fate if the next scroll event came straight after and the pendingScrollTimeout still existed the function would just return so it might in effect be swallowing scroll events, didn't actually verify that this was happening
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ya, we actually want it to not dispatch too aggressively - the "redraw" place is an especially performance-critical path, so we want to defer dispatching the scroll event until we're done drawing. And there is no point in queuing up multiple calls if we don't need to - we just want to make sure that a scroll event gets out in response to this. It's essentially 'debouncing' here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Makes sense thanks for explaining
Codecov Report
@@ Coverage Diff @@
## master #2143 +/- ##
==========================================
- Coverage 37.15% 37.14% -0.01%
==========================================
Files 296 296
Lines 12125 12128 +3
Branches 1596 1596
==========================================
Hits 4505 4505
- Misses 7369 7372 +3
Partials 251 251
Continue to review full report at Codecov.
|
Issue: The
onScroll
event we expose fromNeovimInstance
(and whichNeovimEditor
/OniEditor
depend on to power theonBufferScrolled
event for theEditor
interface) doesn't work reliably - it only dispatches when the cursor moves. However, there are lots of scroll cases where the cursor doesn't move, like:zz
and scrolling by a single line (<C-e>
)It's easy to repro by adding an event listener in the dev tools:
For those cases above, there will be no output.
Defect: Neovim doesn't expose a
Scroll
autocommand, so we rely on a few things to power that event. The cursor moved events trigger this today, but there is also a redraw event that lets us know when there is an incremental scroll - we weren't using that at the moment.Fix: Hook up the
onScroll
event to use the scroll redraw message to work reliably in cases where the cursor doesn't move.Remaining work:
onBufferScrolled
handler build-over-build 😄