feat: scroll primary-screen sessions with the mouse wheel in boo ui#28
Merged
Conversation
The ui dropped wheel events over the viewport unless the application had asked for mouse reporting. Now the view terminal keeps 512KB of scrollback and the wheel pages through it: scrolling pins the viewport, hides the session cursor, and shows a bottom-row hint; wheeling back down or a lone Esc returns to live output, and typed input snaps back first so it lands where the user can see it. The daemon's passthrough strips alternate-screen toggles, so clients cannot tell which screen an application is on. A new .screen protocol message, sent with every repaint (attach, redraw, screen switches), carries that state; full-screen applications get three arrow keys per wheel tick instead, matching terminals' alternate-scroll mode.
Merged
kylecarbs
added a commit
that referenced
this pull request
Jun 11, 2026
Wheel scrollback in boo ui (#28).
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
1 participant
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.
Summary
Wheel events over the
boo uiviewport were dropped unless the application had asked for mouse reporting. Since the client renders from terminal state and is never on an alternate TTY itself, the wheel can drive proper scrollback instead:scrollback wheel down or esc to return.The daemon's passthrough strips alternate-screen toggles, so clients cannot tell which screen an application is on. A new
.screenprotocol message (payloadalt/primary, sent with every repaint, which accompanies attach, redraw, and screen switches) carries that state. Full-screen applications (vim, less, htop) get 3 arrow keys per wheel tick instead, matching terminals' alternate-scroll mode; SS3 variants when the app enabled cursor-keys mode. Apps that request mouse reporting keep receiving raw wheel events, unchanged.boo attachis intentionally unchanged: capturing the wheel there would require enabling mouse reporting on the user's real terminal, breaking native text selection.Validation
zig build test-all --summary all: 122/122 (2 new integration tests).zig build test-all -Doptimize=ReleaseSafe: 122/122.ui: wheel scrolls primary-screen scrollback(streams 40 lines throughcat, wheels to the clamped top, asserts the first line and the hint render, lone Esc returns to the bottom) andui: wheel sends arrows to alternate-screen applications(app on alt screen, one wheel tick arrives as^[[A^[[A^[[Aviacat -v).Caveat
Scrollback accumulates from the moment the ui focuses a session; the attach repaint seeds the active screen only. Earlier history is still available via
boo peek --scrollback. A history-seeded repaint behind a protocol flag is a possible follow-up.This PR was generated with Coder Agents on behalf of @kylecarbs.