Repository navigation
Accumulate high-resolution wheel events forwarded to mouse-tracking apps - #660
Merged
Merged
Conversation
Contributor
Author
|
Looks like tests need to be updated (and maybe some new ones added). I'll try to do this a bit later. |
mrcnski
force-pushed
the
fix-wheel-scroll-speed
branch
from
August 30, 2026 22:19
44dd96b to
4392bdc
Compare
dakra
force-pushed
the
fix-wheel-scroll-speed
branch
from
September 2, 2026 17:16
4392bdc to
6133b38
Compare
With pixel-scroll-precision-mode (or ultra-scroll) Emacs stops coalescing wheel events and emits one per trackpad tick, and every tick was forwarded as a full button-4/5 press, so a short swipe scrolled htop and vim by many rows. Bank each event's pixel delta and send one press per full row of travel, as ghostty does. A mouse-wheel notch stays one press: X11 and pgtk identify the device, macOS reports a line count. A native ghostel--mouse-tracking-p reads the encoder's mouse mode so a sub-row tick can be consumed without sending anything, while wheel events on an untracked terminal still fall through to the user's scroll package.
dakra
force-pushed
the
fix-wheel-scroll-speed
branch
2 times, most recently
from
September 2, 2026 17:50
05d8dcd to
1a1b0cb
Compare
Owner
|
Thanks. I squashed the commit and made a few changes. Also removed the defcustom. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes wheel scrolling being far too fast in mouse-tracking apps (vim, htop, Claude Code) when a pixel-precision scroll package is active.
Problem:
pixel-scroll-precision-modeand ultra-scroll disable wheel-event coalescing, so one trackpad gesture arrives as dozens of small-delta wheel events. The scroll intercept forwards each one to the terminal as a full wheel click. Follow-up to #97, which made non-tracking buffers fall through to the user's scroll package but left the forwarded path at one click per event.Fix: accumulate pixel deltas per buffer and forward one wheel click per cell height of travel, as ghostty itself does. Events without pixel data (classic one-notch-per-event wheels) still forward one click each. A new
ghostel-mouse-scroll-multiplieroption (named after ghostty'smouse-scroll-multiplier) tunes the rate.Since events absorbed into the accumulator must be consumed without sending anything, the tracking check moved out of the send: a new native
ghostel--mouse-trackingexposes the terminal'sflags.mouse_event— the same state the mouse encoder consults — and X10-only tracking falls through to the user's scroll package, since X10 never reports wheel buttons.Tested on macOS (NS build) with a trackpad against Claude Code; plain-shell buffers still fall through to ultra-scroll as before. Untested on the emacs-mac port, where wheel events may lack the pixel-delta slot — the guard makes that case behave exactly as before this change.
🤖 Generated with Claude Code