Summary
The Editor default key bindings are declared platform-uniformly — every entry in Editor.Commands.cs (and the base View.DefaultKeyBindings it layers on) uses Bind.All(...), with no Macos variants. They have never been validated against a real macOS terminal. Several of the default chords are routinely intercepted by macOS itself before they reach the app, so the corresponding editor commands are effectively unreachable on a stock Mac.
The code already acknowledges this is unverified — Editor.Commands.cs carries the note:
// macOS uses the same chord pending real-terminal validation (specs/decisions.md DEC-006).
This issue tracks doing that validation and adding Mac-appropriate bindings where needed.
Affected default chords on macOS
| Command |
Chord |
macOS conflict |
InsertCaretAbove / InsertCaretBelow |
Ctrl+Alt+Up / Ctrl+Alt+Down |
Mission Control / app-window grabs |
WordLeft / WordRight (+ …Extend) |
Ctrl+Left / Ctrl+Right (+Shift) |
Mission Control "move between Spaces" |
| (base) navigation |
various Ctrl+arrow combos |
same Spaces/Mission Control interception |
Whether a given chord reaches the app depends on the emulator (Terminal.app, iTerm2, Ghostty/kitty) and the user's System Settings → Keyboard → Shortcuts → Mission Control state, which makes the current "one keymap for all platforms" assumption unsafe on macOS.
Downstream evidence: the winprint TUI (a consumer of this control) already had to work around the same class of problem in its preview pane — it documents old Ctrl+PageUp/Down/Home app bindings as "dead on macOS (intercepted by Mission Control)" and moved zoom to +/=/-/0.
Ask
- Validate the
Editor default keymap on real macOS terminals (Terminal.app, iTerm2, Ghostty/kitty), per DEC-006.
- For the chords macOS intercepts, add
Macos-specific bindings (the PlatformKeyBinding.Macos slot already exists) or document the recommended user remap.
- Note that there is no
Cmd-key support today — decide whether Mac users should get Cmd-based equivalents for clipboard/undo/select-all to match platform expectations.
Notes
No Cmd bindings exist; the keymap is identical to Windows/Linux. This is a tracking/validation issue, not a regression.
Summary
The
Editordefault key bindings are declared platform-uniformly — every entry inEditor.Commands.cs(and the baseView.DefaultKeyBindingsit layers on) usesBind.All(...), with noMacosvariants. They have never been validated against a real macOS terminal. Several of the default chords are routinely intercepted by macOS itself before they reach the app, so the corresponding editor commands are effectively unreachable on a stock Mac.The code already acknowledges this is unverified —
Editor.Commands.cscarries the note:This issue tracks doing that validation and adding Mac-appropriate bindings where needed.
Affected default chords on macOS
InsertCaretAbove/InsertCaretBelowCtrl+Alt+Up/Ctrl+Alt+DownWordLeft/WordRight(+…Extend)Ctrl+Left/Ctrl+Right(+Shift)Ctrl+arrow combosWhether a given chord reaches the app depends on the emulator (Terminal.app, iTerm2, Ghostty/kitty) and the user's System Settings → Keyboard → Shortcuts → Mission Control state, which makes the current "one keymap for all platforms" assumption unsafe on macOS.
Downstream evidence: the winprint TUI (a consumer of this control) already had to work around the same class of problem in its preview pane — it documents old
Ctrl+PageUp/Down/Homeapp bindings as "dead on macOS (intercepted by Mission Control)" and moved zoom to+/=/-/0.Ask
Editordefault keymap on real macOS terminals (Terminal.app, iTerm2, Ghostty/kitty), per DEC-006.Macos-specific bindings (thePlatformKeyBinding.Macosslot already exists) or document the recommended user remap.Cmd-key support today — decide whether Mac users should getCmd-based equivalents for clipboard/undo/select-all to match platform expectations.Notes
No
Cmdbindings exist; the keymap is identical to Windows/Linux. This is a tracking/validation issue, not a regression.