v0.77.0
What
F3 drops out of the footer entirely while Details is pinned on via
Settings (both the main list and F2's view picker), and reappears the
moment it's turned back off.
Why
Direct follow-up to the previous PR, raised live: "why don't we hide
F3 in the bottom menu, when it is basically unusable?"
Pushed back on the framing first — F3 is only inert in the one
narrow, self-chosen state (Details pinned via Settings), not in
general — and pointed at an existing precedent that argues against
hiding footer items on principle: F9/Presets stays visible even
without tmux specifically because an earlier version hid it, and that
meant nobody without tmux ever discovered Presets existed at all.
Asked how to proceed given that tension; the answer was a general
principle — "hide menus in general that are not usable" — applied
here to the specific case under discussion.
Implementation
Both footer call sites that carry an F3 entry now build it
conditionally on DETAILS_PINNED:
footer_actions()(main list) — conditional append.pick_view()'s (F2)view_footer_specs— built as an array, F3
only added when unpinned.
Deliberately not extended to F9/Presets-without-tmux or any other
"sometimes unusable" item — that would override a different, already-
reasoned decision well outside what was asked about here.
Verification
- Both call sites checked as source text.
test/details-pinned-f3-fixtures.shextended: live tmux run
confirms F3 is present with Details off, gone from both footers the
instant it's pinned on (every other entry still shown), and back
once unpinned (with the pane closing too).- Proved the test catches the regression two ways per call site
(guard absent; guard present but defeated by an unconditional
append right after) before restoring. - Full local suite passes.
- README,
--help, F1's Settings Reference topic updated.
🤖 Generated with Claude Code