Keymap Profiles

mnml ships two complete keymaps. The vim profile gives a Neovim / NvChad user the chords their hands already know: Space as the leader, Ctrl-W for windows, g d / K / [ d for the language server. The standard profile gives a VS Code user theirs: Ctrl shortcuts, the Ctrl+K … chords and the function keys.

Pick one with .editor.input_style = .vim or .standard in config.zon, or for one launch with --input vim|standard.

Every default chord belongs to one of three sets: both (it fires in either profile), vim (only under .vim) or standard (only under .standard). In config.zon, .keys.global applies to both profiles and .keys.vim / .keys.standard add to or override their own.

How the profiles differ

1. Vim keeps the editor's Ctrl keys. Ctrl-W, Ctrl-G, Ctrl-D, Ctrl-U, Ctrl-E, Ctrl-Y, Ctrl-R, Ctrl-N, Ctrl-H, Ctrl-J, Ctrl-T, Ctrl-F, Ctrl-B and Ctrl-O all mean something in Neovim's normal or insert mode, so a default chord that starts with one of them is standard-only. The exceptions are the ones NvChad maps itself in normal mode, which the vim profile binds the way NvChad does: Ctrl-N toggles the file tree, and Ctrl-H / Ctrl-J / Ctrl-K / Ctrl-L move between windows.
2. Ctrl+K is the standard profile's leader; Space is vim's. In the vim profile Ctrl-K is NvChad's window-up. In the standard profile Ctrl+K starts a VS Code chord: press the next key straight away and the chord runs. Pause after Ctrl+K (or after Ctrl+K g) and a popup lists what can follow — w → close others, g → +git (1), including your own .keys overrides. The next key runs the chord as if you had not paused, Esc cancels, and a key no chord uses says no Ctrl+K chord: …. The palette's Leader menu (which-key) opens the same popup. Wherever VS Code defines a Ctrl+K chord for a command mnml has, the standard profile uses VS Code's meaning.
3. Ctrl+] / Ctrl+[ indent and outdent in standard, as in VS Code. In vim Ctrl-] jumps to the matching bracket.
4. Ctrl+L selects the line in standard and moves to the window on the right in vim, so Redraw (view.redraw) has no chord in either profile; it is in the palette.
5. No chord is lost. When a profile-only chord lands on a key a shared command used, the shared command moves to the other profile's chord instead of disappearing.
6. Back / forward (nav.back / nav.forward) are on Alt+← / Alt+→, except on macOS, where those two keys are left unbound.
7. A menu row prints the profile's chord. In standard that includes the keys the editor answers itself — Cut Ctrl+X, Copy Ctrl+C, Paste Ctrl+V, Undo Ctrl+Z, Select all Ctrl+A, Toggle comment Ctrl+/ — and never a leader chord: a command whose only chord is a Space … row prints none, and the hover help says which leader row reaches it. The vim profile prints its leader chords.
8. The menu bar's Alt+letter mnemonics keep every letter in standard, as VS Code's do; in vim a chord the keymap binds wins (Alt+H is NvChad's scratch terminal, Alt+R regex search) and only unbound letters open their menus (menu_bar.interceptKey).
9. The hover help ends on the click's chord. A control whose left click runs one command — a chrome button, a statusline chip, a rail icon, a panel or tree header chip, a launcher dock entry, a menu or palette row — closes its info-view entry with Key: …, that command's chord under the same rule as a menu row (Key: Ctrl+K Ctrl+T in standard, Key: Space t t in vim for the theme pill); no line when the profile binds it to nothing, or when the entry's own [chord] rows already print it. The click and the line read one table, src/app/primary_command.zig.

Chords that differ between the profiles

Sections and columns

Every activity section lives in one of two columns, left or right. The vim profile moves them with Neovim's window keys, read from a focused section; the standard profile has no chord for the moves — use the palette, the rail's right-click menu (Move to right / left side) or :sidebar left|right.

With ui.sidebar = .auto or .hidden the columns float over the editor instead of taking room beside it: view.toggle_tree and view.toggle_right_panel show and hide that overlay, and every command that shows a section (view.activity_*, view.focus_tree, <leader>e) reveals it. view.sidebar_pin docks the column for the rest of the session without editing the config; run it again to unpin.

In an editor Ctrl-W H / L keep Neovim's meaning — move the split to the far edge; only a focused section or the tree reads them as a side move. Ctrl-W J / K work the same way: the section goes into the dock and comes back up to the column it came from. Lowercase j / k move the focus, and reach the dock because it sits under everything. Ctrl-W + / - / > / < resize the window the keys are in: a row of the dock, or two cells of a focused column.

Debugger

Both profiles reach every dap.* command: the vim profile through nvim-dap's leader chords (a +debug group under <leader>d), the standard profile through VS Code's function keys. The function keys work in both profiles, so a vim user has them too.

The +debug group, and the +lsp rows under r such as NvChad's <leader>ra (rename), appear only in the vim profile's leader popup.

The leader popup

The popup that opens after the leader (Space in vim, a pause after Ctrl+K in standard) lists exactly the chords you can type: a chord typed fast and the same chord walked through the popup are one entry, labelled with the command's short name. Its header names the key that opened it — <leader> in vim, Ctrl+K in standard.

Following NvChad: <leader>h / <leader>v are the terminals and the HTTP group is <leader>R; <leader>w is the prefix of wK, not a save; <leader>x closes the buffer. The waiting-session jumps are <leader>aj / ak under +ai/term, the Lua line runner <leader>Ll under +lang/run, and the split zoom <leader>sz.

Inside the popup Backspace goes back one level; a key that is not a character — an arrow, Enter, a function key — leaves the popup open; and a key no row carries says no leader mapping: Ctrl+K … / <leader>… instead of closing it silently. A vim operator waiting for its next key (g, z, Ctrl-W) shows the same popup titled Vim: <prefix>, without the glyph column, since its rows are motions rather than groups.

Every row has a glyph and every group its chord count — 󰍉 f → +find (8) — and a sub-level's header repeats that group's row (<leader>f +find (8); in standard, Ctrl+K f +find (4)). Each glyph has a one-cell --ascii twin.

Ctrl-O, Ctrl-I and Tab in the vim profile

• Normal-mode Ctrl-O goes back through the jumplist (nav.back); insert-mode Ctrl-O runs one normal-mode command. That is why the file picker's Ctrl+O is standard-only.
• Tab / Shift+Tab are NvChad's bufferline (buffer.next / buffer.prev), not Neovim's jumplist-forward. Ctrl-I and Tab are the same byte on a terminal without the kitty keyboard protocol, so there the bufferline wins; with the kitty protocol Ctrl-I still goes forward in the jumplist (nav.forward), and Ctrl+Tab does on every terminal.

A shifted Tab has one spelling

No terminal sends Tab with a Shift modifier: it sends its own back-tab code instead. So shift+tab, <S-Tab>, shift+backtab and backtab all name the same chord, and ctrl+shift+tab is ctrl+backtab — whether you write it in .keys, a .test script or an IPC key command.

Shifted function keys on a terminal without the kitty protocol

Nine commands sit on Shift+F keys in both profiles (find.prev Shift+F3, dap.terminate Shift+F5, git.diff_prev_file Shift+F7, git.conflict_prev Shift+F8, dap.toggle_breakpoint_conditional Shift+F9, view.context_menu_at_focus Shift+F10, dap.step_out Shift+F11, lsp.references Shift+F12, and dap.restart on Ctrl+Shift+F5); the standard profile adds help.focus on Shift+F1 and lsp.peek_definition_overlay on Ctrl+Shift+F10. How they arrive depends on the terminal:

The last two send a different key rather than a modified one, and mnml reads them by what $TERM_PROGRAM / $TERM name: Terminal.app sends Shift+F5–F12 as F13–F20; rxvt and the Linux console send Shift+F3–F10 as F13–F20 and Shift+F11 / F12 as CSI 23 $ / CSI 24 $; anywhere else F13–F20 are xterm's names for Shift+F1–F8. Two chords stay out of reach there: rxvt's Shift+F1 / F2 are the same bytes as F11 / F12, and neither Terminal.app nor rxvt sends anything for Ctrl+Shift+F5 — dap.restart has <leader>dR and the palette. On rxvt the standard profile's help.focus (Shift+F1) is out of reach the same way; it is in the palette too.

Quick open's prefixes — and the non-kitty route to the palette

Ctrl+P opens Open file, and the first character typed picks a mode, the way VS Code's quick open does:

Only a leading prefix counts, so src/a>b.txt stays a path.

> matters on some terminals. The palette is on Ctrl+Shift+P and the leader's space p, and a terminal without the kitty keyboard protocol cannot tell Ctrl+Shift+P from Ctrl+P — both are byte 0x10. On Terminal.app, Alacritty's default config or tmux without passthrough, Ctrl+Shift+P therefore opens the file picker, and > is the way to every command that has no chord of its own (view.focus_dock, view.dock_cycle_mode, editor.highlight_this_file, view.reveal_in_tree, …). keys.doctor does not test for this.

Insert mode and the window keys

Ctrl-H / Ctrl-J move between windows in the vim profile, but in insert mode the editor receives them as Neovim does (backspace and newline): the window move fires from normal mode or from a pane that is not an editor. That matches NvChad, whose <C-h> window map is normal-mode only.