You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a keyboard-heavy Dispatch user, I want the ? help overlay and short help bar to show my actual configured shortcuts so I do not have to mentally translate defaults after remapping keys in config.json.
flowchart TD
A[Load config keybindings] --> B[Apply overrides in internal/tui/keys.go]
B --> C[Render help from effective keyMap]
C --> D[User sees current shortcuts]
Loading
Problem
internal/tui/keys.go already centralizes default bindings, remappable action names, and applyKeybindingOverrides, but internal/tui/components/help.go renders a hand-crafted static overlay. That overlay omits newer actions such as fullscreen preview, command palette, timeline, compare, tags, alias, open file/directory/ref, and copy resume command, and it cannot reflect custom keybindings values described in docs/keybindings.md and README.
Proposed solution
Refactor the help overlay to consume the effective keyMap.FullHelp() and ShortHelp() data after config overrides are applied, preserving the grouped visual layout in internal/tui/components/help.go. Add grouping labels near keyMap.FullHelp() or an adjacent metadata table so the overlay stays readable, update internal/tui/components/help_test.go and internal/tui/keys_test.go, and refresh README/docs examples if the displayed groups change.
User impact
Custom keybindings become discoverable in the UI, new shortcuts stop being hidden from help, and contributors only need to update one keybinding registry when adding actions.
Acceptance criteria
The ? overlay displays the effective keys after keybindings overrides are applied.
The short help bar uses the same effective bindings instead of hard-coded default labels.
All actions in keybindingEntries are represented in grouped help output or intentionally documented as hidden.
Tests verify a custom binding appears in the overlay and a newly added binding cannot drift silently from help coverage.
README or docs/keybindings.md notes that in-app help reflects custom bindings.
As a keyboard-heavy Dispatch user, I want the
?help overlay and short help bar to show my actual configured shortcuts so I do not have to mentally translate defaults after remapping keys inconfig.json.flowchart TD A[Load config keybindings] --> B[Apply overrides in internal/tui/keys.go] B --> C[Render help from effective keyMap] C --> D[User sees current shortcuts]Problem
internal/tui/keys.goalready centralizes default bindings, remappable action names, andapplyKeybindingOverrides, butinternal/tui/components/help.gorenders a hand-crafted static overlay. That overlay omits newer actions such as fullscreen preview, command palette, timeline, compare, tags, alias, open file/directory/ref, and copy resume command, and it cannot reflect customkeybindingsvalues described indocs/keybindings.mdand README.Proposed solution
Refactor the help overlay to consume the effective
keyMap.FullHelp()andShortHelp()data after config overrides are applied, preserving the grouped visual layout ininternal/tui/components/help.go. Add grouping labels nearkeyMap.FullHelp()or an adjacent metadata table so the overlay stays readable, updateinternal/tui/components/help_test.goandinternal/tui/keys_test.go, and refresh README/docs examples if the displayed groups change.User impact
Custom keybindings become discoverable in the UI, new shortcuts stop being hidden from help, and contributors only need to update one keybinding registry when adding actions.
Acceptance criteria
?overlay displays the effective keys afterkeybindingsoverrides are applied.keybindingEntriesare represented in grouped help output or intentionally documented as hidden.docs/keybindings.mdnotes that in-app help reflects custom bindings.Complexity
S