Skip to content

status: nest a spawned lane under the lane that spawned it - #494

Merged
JulienMartel merged 4 commits into
mainfrom
worktree-omit-child-lanes
Aug 29, 2026
Merged

status: nest a spawned lane under the lane that spawned it#494
JulienMartel merged 4 commits into
mainfrom
worktree-omit-child-lanes

Conversation

@JulienMartel

Copy link
Copy Markdown
Contributor

What

bench status's lane table draws a lane spawned from a pane — scruff child reaching into a second repo, or ⌘↵ pressed inside another lane — indented under the lane that made it, marked .

  workshop     worktree-omit-child-lanes        dirty  ~/.cache/scruff/workshop/omit-child-lanes
  scruff       └ worktree-omit-child-lanes      ·      ~/.cache/scruff/scruff/omit-child-lanes
  haus         └ worktree-omit-child-lanes      ·      ~/.cache/scruff/haus/omit-child-lanes

Why

A workshop lane and the three child repos it opened read as four unrelated lanes in registry order. They are one piece of work.

They are indented, never dropped. The branch is that lane's own, it gets its own PR, and closing the parent's pane does not reap it — this table and scruff are the only places it surfaces once that pane is gone. Two rules keep that honest: a child whose parent bench does not list (someone else's repo) stays at the top level, and a child printed in a different block from its parent (live child, parked parent — exactly what survives a closed pane) is demoted rather than drawn pointing at a row that isn't there.

branch_cell pads by columns for the reason dirty_cell does: is three bytes and one column. It computes the full-cell case rather than measuring it, because ${#b} counts bytes under LC_ALL=C and is three of them — measured, the pad went negative and printf padded the other way.

Verify

nix shell nixpkgs#bats -c bats test/bench.bats     # 190/190
./bench status
LC_ALL=C ./bench status                            # columns hold in either locale

Watch out

  • The doc line added to docs/workflows.md says the palette's Lanes picker is the one surface that drops these. That is true only with hausfold/haus#… (branch worktree-omit-child-lanes, same lane) merged — land them together, or drop that parenthetical.
  • scruff nests the same way via list: nest spawned lanes, and publish where each lane's chat lives scruff#93. Independent: neither PR needs the other, and nothing here reads scruff's output.
  • lane_rows grew a sixth field (parent); lane_table is its only consumer.

🤖 Generated with Claude Code

https://claude.ai/code/session_011T9Lb6mUXWEudUcs2E1B9X

JulienMartel and others added 4 commits August 29, 2026 08:44
A lane whose parent is not its own main checkout came from a pane —
`scruff child` reaching into a second repo, or ⌘↵ pressed inside another
lane. Those rows now indent under the lane that made them instead of sitting
in registry order, where a workshop lane and the three child repos it opened
read as four unrelated lanes.

They are indented, never dropped. The branch is that lane's own, it gets its
own PR, and closing the parent's pane does not reap it — this table and
`scruff` are the only places it surfaces once that pane is gone. A child whose
parent bench does not list (someone else's repo) stays at the top level rather
than hiding under an invisible row.

branch_cell pads by columns for the reason dirty_cell does: `└` is three bytes
and one column, so %-32s came up two short on every indented row.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011T9Lb6mUXWEudUcs2E1B9X
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011T9Lb6mUXWEudUcs2E1B9X
Follow-ups from the pre-PR assurance pass.

lane_rows hands the tree over parent-first, but lane_table then SPLITS those
rows into a live block and a parked one — so a live child of a parked parent
led the table with a `└` and nothing above it. That is the headline case, not
an edge: a child is exactly what survives when the pane that made it closes and
parks the parent. A row is now indented only under a parent already printed in
the same block, and demoted to the top level otherwise — an indent pointing at
a row that isn't there is worse than no indent.

branch_cell no longer measures the cell it just truncated. `${#b}` counts BYTES
under LC_ALL=C and `…` is three of them, so the pad went negative and printf
honoured that by padding the other way: two stray columns, on truncated rows
only. The full cell needs no padding at all, which is computable.

The legend was 137 cells against the 100-cell prose cap in
docs/cli-presentation.md — it soft-wrapped on any terminal under ~137 columns,
which is the defect that cap exists to name. It is 96 now, beside its
neighbours' 99 and 100.

Dropped the claim that `scruff` nests the same way: true only once its own PR
lands, and a comment is not the place to promise another repo's next release.

The alignment test cut rows at `~/`, which never fired because the suite's tmp
dir is not under $HOME — it compared whole rows and passed on a coincidence.
It now cuts at the dirty marker and covers the truncation path, where the only
real width bug was.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011T9Lb6mUXWEudUcs2E1B9X
`depth` went dead the moment lane_table started deriving the indent from what
it had actually printed (it must: live and parked rows are printed in separate
blocks, so the awk's depth is not the drawn one). shellcheck said so. Dropping
the column leaves one source of truth — lane_rows guarantees a child follows
the lane that spawned it, and how deep it is drawn is the table's call.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011T9Lb6mUXWEudUcs2E1B9X
@JulienMartel
JulienMartel merged commit 63fa9ad into main Aug 29, 2026
2 checks passed
@JulienMartel
JulienMartel deleted the worktree-omit-child-lanes branch August 29, 2026 14:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant