rgitui's keyboard shortcuts are fixed at compile time. crates/rgitui_workspace/src/workspace/key_handler.rs matches keystrokes with a 598-line chain of if key == "..." && modifiers... branches, and roughly 35 more on_key_down handlers across the views do the same locally. Nothing can be rebound.
That has knock-on effects beyond customisation:
- Overlay precedence is hand-maintained. A 12-term
any_overlay_active boolean gates panel shortcuts, and Escape is a 10-branch cascade re-checking each dialog's visibility. The file's own TODO(audit): QUAL-10 already calls for moving to gpui actions and letting the focus/key_context tree resolve precedence.
- The shortcut reference drifts.
shortcuts_help.rs stores literal strings like ("Ctrl+Shift+P", ...), and two more hardcoded lists exist elsewhere. One is already wrong: the help advertises Ctrl+Shift+F for Fetch, but the binding is Ctrl+Shift+R.
- Multi-commit operations are unreachable.
GraphView holds selected_index: Option<usize>, so there is no way to select a run of commits and squash them, even though GitProject::rebase_interactive already supports squash.
There's an existing draft for this in #47, which adds a CustomShortcuts schema to settings.
PR #62 proposes a different approach: a commands! macro as the single source of truth generating gpui actions, a Zed-shaped keymap.json, conflict detection, a keymap-derived shortcut panel, and squash-selected-commits on top. It stacks on #60. #62 explains how it relates to #47 — happy to go whichever way you prefer.
rgitui's keyboard shortcuts are fixed at compile time.
crates/rgitui_workspace/src/workspace/key_handler.rsmatches keystrokes with a 598-line chain ofif key == "..." && modifiers...branches, and roughly 35 moreon_key_downhandlers across the views do the same locally. Nothing can be rebound.That has knock-on effects beyond customisation:
any_overlay_activeboolean gates panel shortcuts, and Escape is a 10-branch cascade re-checking each dialog's visibility. The file's ownTODO(audit): QUAL-10already calls for moving to gpui actions and letting the focus/key_context tree resolve precedence.shortcuts_help.rsstores literal strings like("Ctrl+Shift+P", ...), and two more hardcoded lists exist elsewhere. One is already wrong: the help advertisesCtrl+Shift+Ffor Fetch, but the binding isCtrl+Shift+R.GraphViewholdsselected_index: Option<usize>, so there is no way to select a run of commits and squash them, even thoughGitProject::rebase_interactivealready supports squash.There's an existing draft for this in #47, which adds a
CustomShortcutsschema to settings.PR #62 proposes a different approach: a
commands!macro as the single source of truth generating gpui actions, a Zed-shapedkeymap.json, conflict detection, a keymap-derived shortcut panel, and squash-selected-commits on top. It stacks on #60. #62 explains how it relates to #47 — happy to go whichever way you prefer.