mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 16:02:24 +00:00
`tty7 capture` takes ~323ms against a local daemon and neither constant said why. Measured: a pane that has printed nothing costs the same as one holding 22,000 lines, `--plain` costs the same as raw, and lowering the replay grid's floor from 10,000 lines to 100 changes nothing. The grid work is ~20ms; the rest is `REPLAY_SETTLE` running out. `tty7 pane ls` over the same socket is ~5ms. It is paid because the replay has no end. The daemon sends `Size` then `Snapshot` per ring segment and stops, and the only way to know it has stopped is to wait. Live `Output` cuts the wait short, so a busy pane returns at once — but the idiom the reference recommends is `tty7 wait … && tty7 capture …`, and `wait` returns exactly when the pane has gone quiet. The recommended path always pays in full. No behaviour change; this is the note that was missing. It also records the two wrong ways out, because both look attractive from the outside. Lowering the timer trades a bounded delay for silently truncated output on a slow link or a loaded machine. An end-of-replay message is the real fix and is *not* additive — `DaemonMsg::read` rejects an unknown kind outright, so a daemon sending one to an older client breaks it. That needs a `PROTOCOL_VERSION` bump with the daemon gating on what the peer announced, which is a larger change than a comment.