v0.8.5-alpha

Fixed: scrolling in a terminal could stop working entirely

Two-finger scrolling, or a wheel, did nothing at all in a terminal tab — but only sometimes, which is what made it look random.

Every session in a window lives in one stack of views, all at the same size, the inactive ones simply invisible. That is what keeps an ssh process alive while you work in another tab. The wheel handler added in 0.7.0 was installed once per session and ran for all of them, and its test for "is the pointer over me?" was a check against the view's own rectangle — which every one of those stacked views passes, visible or not.

So a tab left sitting in less, vim or mc answered the wheel first. Being on the alternate screen, it took the event, swallowed it, and sent its arrow keys off into a session nobody was looking at. The terminal actually on screen never heard about it. Close that tab and scrolling came back, which is why it seemed to come and go.

Scrolling is now handled by the tab that is on screen, and no other. The same fix covers a quieter version of the same fault: a hidden tab's leftover selection could overwrite the clipboard on any click in the window.

Fixed: precise scrolling read the wrong value

Inside less and friends the scroll amount was read from the field a mouse fills in with whole notches. A trackpad does not use that field — it reports in points, and leaves the other one rounded down to zero for anything gentler than a flick. A slow, deliberate two-finger scroll therefore had nothing to act on.

Precise scroll deltas are now read from the field they are actually delivered in, added up, and spent a line at a time, so a slow drag moves smoothly instead of not at all.