umputun / agterm / 33490419939

97%

push

github

feat(control): report the foreground shell on a session node (#525)

* feat(control): report the foreground shell on a session node

`tree` omitted `foreground` both when a shell held the pane and whenever the
process could not be read, so a caller could not tell those apart.
`cookbook/park-and-resume` documents that as a data-loss limit: an unreadable
pane is parked as idle, replayed as a plain shell, and the record of what it was
running goes with the deleted workspace.

Session nodes now carry `foregroundShell`/`splitForegroundShell`, the basename of
the recognized shell holding each pane's foreground, present exactly when that
pane's `foreground` is absent because a shell holds it. For a pane that exists,
both absent now means agterm could not read the process.

The field deliberately does not claim the pane is at a prompt, and says so on
every surface. A builtin - `read`, `vared`, a `while` loop - runs inside the
shell process, so argv stays the shell's and a pane blocked waiting for input is
indistinguishable from one at a prompt; libghostty exposes no OSC 133 mark, so
there is no prompt signal to report instead. Treating it as permission to type
would inject into a running `read`. A regression test pins that contract so it
fails loudly if the classifier ever changes.

The split pair needs `hasSplit` to interpret: with no split pane both fields are
absent because there is no pane, not because anything was unreadable. `hasSplit`
stays omitted when false.

CommandRestore gains `PaneForeground` and a `paneForeground` classifier;
`ForegroundProcess.running` returns it while the restore capture collapses the
shell case back to nil, so what a pane re-runs at launch is unchanged. The
basename comes from the dash-stripped argv, in that order - `basename` splits on
`/`, so the reverse order leaves a bare `-zsh` intact.

`AppStore.controlTree`'s primary entry point takes one `PaneForeground` closure
per pane under new labels, and `ControlProtocolCompatibi... (continued)

41 of 41 new or added lines in 4 files covered. (100.0%)

9245 of 9471 relevant lines covered (97.61%)

4308450.17 hits per line