- Shipped
- September 5, 2026 at 5:57 AM UTC
- Author
- Kamo
- Commit
- c85be57
The bar moved xterm's own buffer, and under tmux that buffer never grows: tmux sends the client only the lines that end up visible and keeps the history itself. So `baseY` was always 0, the bar read that as "nothing to scroll", and it I verified it originally against a bare xterm.js writing its own output, which is the one arrangement where it works. It now drives tmux when the buffer is empty, by sending the wheel reports tmux already binds to `copy-mode -e` — the same path the physical wheel takes, so there are not two mechanisms to keep in step. SGR encoding (button 64 up, 65 down), which is what tmux asks for once its mouse mode is on. The local branch stays, because it is correct for a terminal that is NOT hosted by a multiplexer and costs nothing — and because a bar that sent wheel reports at a plain emulator would scroll nothing and be broken in precisely the way this is fixing. Two behaviours had to differ honestly rather than pretend: - The GRIP. With the buffer here the thumb's position IS the position, so dragging scrubs. With the scrollback in tmux nothing can say where in the history the pane is sitting, so the grip becomes a jog wheel — centred, fixed height, scrolling by how far it is pulled. Drawing a thumb at a position we cannot know would be a lie the eye would believe. - The JUMPS. A wheel report cannot say "go to the top", so it is a burst sized from tmux's own default history-limit of 2000 lines. Overshooting is free: tmux stops at the top, and at the bottom it simply leaves copy mode. 13 guards and 5398 tests. check-i18n-keys is red on another session's CalDAV work; this adds no keys.