z widens the readme panel at the brief card's expense

[stanlyzoolo]

Sometimes the readme wants to be wider than 34% of the terminal. z toggles the three-panel split between 20/46/34 and 20/30/50, giving panel [3] the room and taking it from the card. Session-only, nothing persisted.

Mouse border-dragging was the alternative and got rejected as YAGNI in the brainstorm: far more code and edge cases for the same need, and a zoom toggle does not preclude adding drag later.

Binding

z fires from focusBrief || focusHelp — the gate R/H/M already use, since it is the fourth key that changes what [3] is. Unlike that trio it does not move focus (a width change is not a change of what you are reading) and it fetches nothing, so the status expiry tick is the whole returned command.

Below ~82 columns the 15/30/30 minimum clamps produce the same triple for both variants, so the key answers too narrow to zoom and flips nothing rather than setting a flag nothing follows — toggleGroupByTag's refusal, same shape. !m.ready is checked first and explicitly, not left to the clamps agreeing by coincidence.

Structure

panelWidthsFor(zoom bool) is the pure width core; calcPanelWidths() is the one-line wrapper over m.helpZoom. Parameterizing it (rather than copying a Model with the flag flipped) is what lets the toggle compare the two states.

applyLayout() is now the single relayout definition — the WindowSizeMsg handler collapsed to two assignments plus the call, so the resize path and the toggle cannot drift.

One sharp edge, and it gets its own test: the prevWrapW capture must stay above the calcPanelWidths assignment. helpWrapWidth() reads the stored m.helpW, so a capture placed below compares the new width against itself, the re-wrap guard is dead, and [3] silently keeps its pre-resize wrapping — with every other test in the package green.

Accepted consequences

• An active j/k spotlight in [3] is lost on z, and the README re-renders through glamour synchronously (width is part of readmeRenderCache's key). Both are exactly what a width resize already costs.
• Zoom is orthogonal to the [3] update-log takeover: showsUpdateLog() owns content, zoom owns width. Asserted, not left to a manual check.

Chrome

[3]'s footer gains a z zoom cell, placed last so it sheds first, and dropped entirely while an update log owns the panel — same reasoning as the title dropping its source hints there.

Measured shed geometry: the cell survives from ~118 columns in readme mode and ~150 in --help/man, where the entry index adds a j/k navigate cell. The plan guessed ~110; corrected in the docs. Between ~82 and that width the key works unadvertised in the footer, which is the ordinary shed rule — the [?] overlay never sheds and is what documents it at every width.

The overlay merges the e/# rows into e/# note / tags (the o/c idiom) to buy the row for z zoom panel. Column 2 was already at its 16-row budget, so a new binding buys a row rather than appending one. Net rows unchanged in all five self states.

Testing

Every new assertion was mutation-checked: prevWrapW moved below the recompute, the setToolsContent tail dropped, the !ready guard removed, the narrow refusal removed, the gate widened to every focus, the flag flipped without applyLayout, the footer cell removed and un-suppressed under the log, the overlay row removed, and an over-long status in the narrow wrap sweep. All killed. One survived at first — the log-suppression check ran at a width where the cell was shed anyway; the test moved to 160 columns and now bites.

too narrow to zoom joins TestStatusBarNeverWraps' sweep down to 24 columns: it is the one status whose trigger condition is a narrow terminal, and renderStatusBar's statusMsg branch does not truncate.

Full CI matrix green locally, plus the cross-compile steps.

Not done

No look at a real TTY — the rendered output was read through a throwaway probe test at 80/100/110/120/160 (deleted afterwards), which covers layout and shed but not how it feels to press. Worth one manual pass, wide and at 80×24, against a long README.