feat(herd): the mosh bar under a plain attach too - #356
Merged
Conversation
`moshcode attach <name>` had the same shape of problem the workspace did:
once the agent has the keyboard, the "detach with Ctrl-b d" line printed
before handover is gone with its first repaint, and there is nothing on
screen to replace it. So an attached session now grows the same one-line
prompt along the bottom for as long as you are there.
It is taken away again on the way out, so a member is a plain member when
nobody is looking at it. That teardown is not tidiness: `kill` ends a
member by killing its pane, and a session still holding a bar would
outlive the member it was named for and keep answering to its name on the
roster. `killSession` now also takes the room when the bar is all that is
left of it, and `sweepBars` clears what a crashed client could not —
skipping any session with a client attached, because that bar is someone
else's way out.
The jump key had to stop naming a pane. It was bound to the workspace's
bar by id, which is the wrong answer from inside an attached member and
becomes wronger every time a bar is rebuilt. It is now
`select-pane -t {bottom-right}`: in the workspace and under an attach
alike, the bar is the bottom row, so one binding finds it in both.
The bar asks where it is rather than assuming, and `show` means the right
thing in each place — swap the content pane in the workspace, switch the
client under an attach, giving that member a bar before you land in it so
you never arrive somewhere with no way back out.
One thing that only a real client showed: tmux scales panes
proportionally on resize, so a bar built against an 80x24 window came
back THREE rows tall the moment a client attached at 100x30. Nothing
outside the pane can predict when that happens, but the pane gets a
resize event for it, so the bar now keeps itself one row. There is a test
that stretches the window and fails without the fix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ThreatCrush Security Scan93 finding(s) HIGH/CRITICAL: 2 | MEDIUM: 43 | LOW: 48
…and 43 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
Merged
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.
moshcode attach <name>had the same shape of problem the workspace did: the "detach with Ctrl-b d" line printed before handover is gone with the agent's first repaint, and nothing replaces it. An attached session now grows the same one-line prompt along the bottom for as long as you are there.It comes off again when you detach, so a member is a plain member when nobody is looking at it.
The teardown is not tidiness
killends a member by killing its pane. A session still holding a bar would outlive the member it was named for and keep answering to its name on the roster — an empty room with a nameplate. So:killSessiontakes the room too when the bar is all that is left of it;sweepBarsclears what a crashed client could not, skipping any session with a client attached — that bar is someone else's way out, not litter.The jump key had to stop naming a pane
It was bound to the workspace's bar by pane id, which is the wrong answer from inside an attached member and gets wronger every time a bar is rebuilt. Now:
In the workspace and under an attach alike, the bar is the bottom row — so one binding finds it in both, and no rebuild can stale it.
The bar also asks where it is rather than assuming, so
showmeans the right thing in each place: swap the content pane in the workspace, switch the client under an attach — giving that member a bar before you land in it, so you never arrive somewhere with no way back out.What only a real client showed
tmux scales panes proportionally on resize. A bar built against an 80x24 window came back three rows tall the moment a client attached at 100x30:
Nothing outside the pane can predict when that happens, but the pane gets a resize event for it, so the bar keeps itself one row. The test stretches the window and fails without the fix (
bar stretched on resize: api:34).Verification
End to end, with a real second tmux client running the real
moshcode attach:1520 tests pass, 0 fail. New coverage: the sweep rule (attached sessions spared, workspace spared, bar-only windows left alone),
ensureBaridempotence,removeBarrefusing to empty a window, the live on/off round trip asserting the member gets its height back, the orphan guard, and the resize regression.🤖 Generated with Claude Code