You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Touch pan tracks the app's rows-per-report multiplier (touch-only gain request) #267
Pan a long transcript in opencode by touch and have the content follow my finger.
What happens today
Panning runs at the app's per-report multiplier. opencode's default scroll_speed is 3, so one cell of finger travel moves ~3 rows and the screen outruns the finger while dragging. This is the mirror of #245: wmux emits one SGR report per cell crossed (finger semantics), which is exactly 1:1 only where the app's multiplier is 1. Scrollback pan is 1:1 because nothing multiplies it there.
Wheel wants 3 rows per detent, touch wants ~1:1, and both reach the app as the same kind of report, so one scroll_speed cannot serve both. Raised in the #243 follow-up; not addressed by #245 or #248.
What would you like wmux to do?
A touch-only gain so pan can track the finger while the wheel stays at 3:
ideally a setting (Settings or config.toml); a constant is fine too;
applied only to touch-pan events forwarded to a mouse-tracking app, so scrollback touch pan (already 1:1) is not slowed;
do NOT scale the fling: keep its current distance. The glide feels right as shipped and a slow tracking pan into an energetic flick is the feel I want.
At scroll_speed 3 a gain near 1/3 gives 1:1; it needs to be adjustable only because it depends on the app's own multiplier.
What do you do today instead?
scroll_speed 2 (pan 2:1, wheel 2 rows/detent) or 1 (pan tracks, wheel slow). Neither is right: 3 is correct for the wheel, and ~1:1 is correct for the finger.
Settings → Terminal → Touch → Touch pan gain, or in config.toml:
[terminal]
touch-pan-gain = 0.33
The value is reports per cell of finger travel, range 0.05 to 4, default 1 (today's behaviour). The fraction is carried between events, so a slow drag at 0.33 still moves: 30 cells of travel send 10 reports, which is 30 rows at scroll_speed 3.
It applies only to a touch pan forwarded to a mouse-tracking app. Scrollback pan, the arrow-key path for non-mouse pagers and the mouse wheel are unchanged.
The fling is not scaled. It is now tagged as its own source internally, so it keeps one report per line and the distance it had in 2.17.
The setting is read per event, so a change applies to the next drag without reopening the pane.
I have no touchscreen here, so this is covered by unit tests on the report counts and not by a real finger. If the pan-to-flick handoff feels wrong at 0.33 (the pan is now a third of the speed the flick continues at), tell me and I will look at it.
Activity
fix(remote,touch): show the mirror's bottom rows, a real Enter while …
amirlehmam commentedon Oct 2, 2026
Shipped in 2.18.0, as a setting.
Settings → Terminal → Touch → Touch pan gain, or in
config.toml:The value is reports per cell of finger travel, range 0.05 to 4, default 1 (today's behaviour). The fraction is carried between events, so a slow drag at 0.33 still moves: 30 cells of travel send 10 reports, which is 30 rows at
scroll_speed3.It applies only to a touch pan forwarded to a mouse-tracking app. Scrollback pan, the arrow-key path for non-mouse pagers and the mouse wheel are unchanged.
The fling is not scaled. It is now tagged as its own source internally, so it keeps one report per line and the distance it had in 2.17.
The setting is read per event, so a change applies to the next drag without reopening the pane.
I have no touchscreen here, so this is covered by unit tests on the report counts and not by a real finger. If the pan-to-flick handoff feels wrong at 0.33 (the pan is now a third of the speed the flick continues at), tell me and I will look at it.
Mattheinrichs commentedon Oct 2, 2026
Verified on a ThinkPad Z16 Gen 2 (Windows 11), v2.18.0:
Set Settings → Terminal → Touch → Touch pan gain to 0.35 (that's what the spinner allowed) for opencode's default
scroll_speed3.Calling this good. Thanks for the fast turnaround across the whole set (#243, #245, #248, #249, #267).