Bottom status line: keybindings-only, context- and state-aware; add mode advanced to empty hint
#27
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
From manual testing / UX discussion.
The bottom-most UI line currently mixes command words and keystrokes.
That's redundant: the hint panel (when no command is entered) already
teaches that
helpgives help andEntersubmits. Repurpose thebottom line for keyboard bindings only.
Proposed design
Context-sensitive to nav focus (the app already cycles
NavFocus: Input -> SidebarTables -> SidebarRelationships viaCtrl-O):Ctrl-O nav · Tab complete · Up/Down history · Enter runCtrl-O next pane · PgUp/PgDn scroll · Esc inputDrop command words (
help) from the bottom line — they belong in thehint panel, not the keybinding strip.
Include transient states (user preference): when a transient mode
is active, reflect its keys — e.g. while a Tab-completion memo is live,
show
Tab/Shift-Tab cycle · Esc cancel; during history navigation,the relevant keys; etc. So the strip is not purely static-per-focus —
it tracks the current interaction state.
Empty-input hint (simple mode): append a short pointer so advanced
mode is discoverable, e.g.
… · type \mode advanced` for SQL`.Scope / files
ui.rs— the status/keybinding line rendering (context- andstate-aware).
Likely warrants a short ADR if the keybinding strip becomes a
first-class, state-driven UI element. Mentions:
Ctrl-O,PgUp/PgDn,mode advanced.Implemented in
eceedc1— ADR-0051 (context- and state-aware keybinding strip).The bottom status line is now a keystrokes-only, state-selected strip. A pure
status_bar_bindings(app)picks the binding set by priority (first match wins):Ctrl-O next pane · ↑↓/PgUp/PgDn scroll · Esc inputTab/Shift-Tab cycle · Esc cancel · Enter run↑↓ browse · Esc clear · Enter runEsc clear · Ctrl-A/E home/end · Ctrl-W del word · Enter runCtrl-O sidebar · Tab complete · ↑ history · Enter runThe editing state surfaces the #29 readline keys (closing ADR-0049's deferred advertisement). Priority is correct because Up clears the completion memo and Tab cancels history nav, so the completion/history states never co-occur; the five are exhaustive for input focus.
Mode discovery moved off the strip into the empty-input hint — typed-command words (
mode advanced/mode simpleswitch, the:one-shot) andCtrl-C quitare gone from the keybinding line.Refinements after a trial run (this thread):
Ctrl-O nav→Ctrl-O sidebar(clearer than "nav").· `mode advanced` for SQL(the prompt implies typing, as withhelp).helpcovers the way back; a "switch back" pointer only reads naturally right after switching.Decisions (user-confirmed): editing state shows the #29 keys;
Ctrl-C quitomitted (lean, conventional); no width-drop machinery — the longest strip (~65 cols) fits all supported widths, so a width-budget test keeps it lean by construction instead.Out of scope: modal-aware strip (pre-existing — a modal owns the keyboard and carries its own hints; the strip under it is unchanged-in-kind); a full-key cheatsheet overlay; Ctrl-K/U advertisement (the editing strip shows the highest-value subset within the width budget).
Tests: 9 Tier-1 unit (per-state key sets — completion/history driven through real key events; width budget; mode-pointer presence/absence), 1 Tier-3 rewritten (
status_bar_is_keystroke_only_and_state_aware), 15 full-panel snapshots re-accepted (each diff reviewed — strip/hint only). 2467 pass / 0 fail / 0 skip (1 ignored), clippy clean.