3 Commits

Include renames

Author	SHA1	Message	Date
Codeman maintainer	53f61ca539	fix(tiles): the wheel scrolls Claude's fullscreen transcript in a tile, and Shift+wheel scrolls local history ... A grid tile or the split's Pane B (TerminalTile) left the mouse wheel to xterm for a session running Claude's fullscreen renderer (claude 2.1.187+ with mouse tracking on, cliMouseTracking). That renderer scrolls its own transcript on SGR wheel reports, which the primary pane sends it, while the tile's xterm holds only Codeman's replayed repaint frames (tmux keeps no history for such a pane). So in a grid of fullscreen Claude sessions the wheel either scrolled nothing or dragged stale frames, Claude's pinned input box with them, up the tile, and Claude's transcript never moved. This was tile-grid-plan follow-up 4. The tile now forwards the wheel the way the primary pane does (TerminalTile._maybeForwardWheelToCli): the primary pane's own gate, _shouldForwardWheelToApp(ev, target), asked for the tile's terminal and session; the cell from _clientPointToCell(x, y, tile.terminal); a scrolled-up viewport snapped to the live screen first; and the reports flushed through the tile's own 40 ms coalescer to the tile's session (the primary queue flushes to the active session). The encoding moved into pure helpers in terminal-ui.js, CodemanTerminalInput.wheelDeltaWholeLines and sgrWheelReports, which the primary pane's _wheelScrollLines and _sendSyntheticSgrWheel now call too, so the two panes send identical bytes. Shift+wheel, the explicit local-scrollback gesture, was dead in every tile off macOS: Chrome on Windows delivers it as a horizontal wheel (deltaX), and xterm's own scroller turns a Shift+vertical wheel into a horizontal one. The tile now scrolls it itself (_maybeScrollLocalOnShift: scrollLines() on the dominant axis, sub-line travel carried over, a shell tile's history pull still asked on the way up), as the primary pane's capture-phase handler does. Unchanged: inline Claude, opencode and older Claude still take the PageUp/PageDown route (#555), shells and other modes keep xterm's own plain wheel, and a tracking xterm or the alternate buffer stays xterm's. Tests: test/terminal-tile-scroll.test.ts covers forwarding (geometry, tick cap, coalescing, viewport snap, the tile's session rather than the active one, Shift/tracking/alternate exclusions, byte equality with the primary pane) and Shift+wheel (Windows deltaX shape, sub-line carry, shell history pull). test/terminal-tile-scroll.browser.test.ts adds a real-Chromium case with trusted page.mouse.wheel() events. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-10-10 02:25:54 +02:00
Codeman maintainer	24a73ecd81	fix(tiles): page a hollow tile only from the live screen, review follow-up ... A tile counts as hollow when every row above its screen is its own overflow (baseY minus _overflowRows is 0), so unlike the primary pane, whose hollow buffer has baseY 0, its viewport can sit above the bottom while it is hollow: Shift+PageUp, a scrollbar drag or a wheel during the first replay leave it up there. _maybePageCliTranscript never looked at the viewport, so every wheel, wheel-down included, was turned into PageUp/PageDown and swallowed. xterm never scrolled back, the stale rows stayed on screen while the CLI paged out of view, and clicks were dropped too, because the click report refuses an off-bottom viewport. The tile now pages only while _terminalViewportAtBottom holds for its own terminal, checked before the pending travel is touched. Off the bottom the wheel stays with xterm, so a wheel-down brings the viewport home and paging resumes from there. The primary pane is unchanged: its hollow test already implies a viewport at the bottom, which the twin comment now says. Tests: a unit case for a tile hollow by the discount with its viewport above the bottom (no page key, no preventDefault, and no travel carried over once back home), and the real-browser case now scrolls a hollow tile up and proves a real wheel-down scrolls xterm home with no page key sent, then pages again. Both go red with the gate removed, and the unit case also with the gate moved below the pending-travel update. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-10-09 08:40:04 +02:00
Codeman maintainer	4fe843a94e	fix(tiles): page a hollow tile's CLI transcript and report its clicks (#555 parity) ... #555 made the primary pane page opencode's transcript with PageUp/PageDown from the wheel, because opencode draws in place on the alternate screen and leaves the browser's buffer with no scrollback. A TerminalTile (a grid tile, the split's Pane B) left every wheel to xterm, so in an opencode tile the wheel scrolled nothing, or only stale rows. The tile now runs the primary pane's own gates aimed at itself (its terminal, its session, never the active one): xterm's tracking mode, the Claude forwarding gate, then the hollow-buffer test. A wheel that passes them is consumed in the capture phase and turned into PageUp/PageDown through the shared pageKeysForTravel math, coalesced per tile (40 ms, 512 bytes, the twin of the primary pane's queue) and sent ephemeral on the tile's own socket. Every other wheel stays with xterm as before, the shell history pull included. The file names no CLI: the mode rules stay in terminal-ui.js, and terminal-tile.js joins the frontend no-id-branching guard. A plain port of the primary's baseY === 0 test would almost never fire in a grid. A tile's first capture is taken at the PTY's previous size (usually the taller primary pane's) and written into a shorter xterm, and its own row-shrinking fits (zoom-out, divider drags, tile count changes) push more rows above the screen. The tile counts those rows as its own overflow: all of them after a load whose capture held a single screen (the server's captureRows), plus whatever a local fit or a PTY geometry report pushes up, reset by a clear and clamped to baseY. The paging gate gets baseY minus that count. Output that scrolls real lines still counts as history, so the tile stops paging there. #555's other half, stripping opencode's mouse DECSETs so a drag selects text, is server-side and already reached tile sockets. It also left the tile's xterm unable to encode opencode's clicks, so the tile now installs the primary pane's desktop click report (bubble phase, gated on the session's cliMouseTracking, the tile's own link hover and selection). Both listeners, the flush timer and the page-key state are torn down in destroy(). Still out of scope, as the fileoverview now says: touch paging (tiles have no touch path) and SGR wheel forwarding to Claude's fullscreen renderer (tile-grid-plan follow-up 4), so a fullscreen Claude tile keeps leaving the wheel to xterm. Tests: test/terminal-tile-scroll.test.ts drives a real tile in the vm harness (session targeting, every no-page case, accumulation, the cap, coalescing, byte parity with the primary pane, the overflow discount through a load, a fit, a geometry report and a clear, the click report and destroy); the discount cases fail with it removed. The fake xterm gains opt-in row emulation. test/terminal-tile-scroll.browser.test.ts checks the same model against a real xterm with trusted wheel events (browser suite, not the gate). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-10-09 07:35:29 +02:00