Shortcuts

Every keyboard shortcut outl ships with, across every client, in one table per concern.

Source of truth

Why one catalog owns every chord, and why the desktop has no character cursor: RFC 0070.

The desktop and TUI both pull their chord catalog from crates/outl-shortcuts (src/defaults.rs::default_bindings()). The mobile app doesn’t expose a keyboard surface (touch + on-screen keyboard); the rows below leave its column blank when there’s nothing to bind.

One catalog, two consumers — and only one of them resolves through it. The desktop calls outl_shortcuts::lookup(mode, chord) → Action for every keystroke, so a chord change in defaults.rs reaches it on the next build. The TUI does not. It dispatches Normal-mode keys through its own match in input/normal.rs, and input/chord_adapter.rs exists only to match plugin-contributed chords. The catalog and those match arms can disagree without anything failing to compile; a handful of reminder chords are pinned by reminder_chord_tests, and the rest are not. Treat a TUI cell below as documentation of the match, not of the catalog.

If a row below disagrees with what you observe in the app, the code is right and this doc is stale — file an issue or fix the row.

Which client performs which action is not this doc’s to answer, and the three times it tried it was wrong (see the rows fixed in the same commit as this note). That fact lives in outl_shortcuts::support and is rendered in client-parity.md, which is generated and test-pinned. This table says which key; that one says whether anything happens.

How to read the tables

• Chrome / Global chords fire in every mode.
• Normal / Insert / Visual / Overlay mirror the vim modes. The desktop subscribes to Normal/Visual only while editor.vim_mode = true (see docs/config.md); chrome and Insert chords are always live.
• Cmd is the macOS modifier; Ctrl is the same chord on Linux / Windows / TUI. We list one form per row to keep the table readable.
• A chord in the form q q is a vim-style two-key sequence: press the first, then the second within ~1 s.

Chrome (Global) — works in any mode

Why Cmd+J and not Cmd+T for today’s journal? Every outliner ecosystem uses T for task / TODO — TUI’s Ctrl+T, Logseq’s Cmd+T, the universal Markdown checkbox shortcut. Re-training that muscle memory would be hostile. J for journal is unambiguous and lines up with the TUI’s g j chord.

Defaults the user often asks about. Both clients ship with sidebar and backlinks panel HIDDEN (show_sidebar: false, show_backlinks: false). Editor-hero on first launch — the user opts the panels in with the chord. This matches Bear / Ulysses on the desktop and outl-tui’s historical behaviour.

Why the shifted variants for sidebar / backlinks

So Cmd+Shift+E (VS Code’s “Show Explorer”) and Cmd+Shift+B are the canonical chrome chords on the desktop. The TUI mirrors the spirit with Ctrl+E / Ctrl+B (most terminals collapse Ctrl+Shift+letter into Ctrl+letter, so both forms work identically).

Inline markdown — Insert mode (textarea focused)

Wrap the current selection (or insert the delimiter pair around the caret). Mirrors the convention every markdown editor on the planet ships.

outl ships _…_ as the canonical italic. The parser still accepts *…* for compatibility, but .md projections emit underscores.

Outline navigation — Normal mode

The desktop honours Normal/Visual only while editor.vim_mode = true. The TUI is vim-style by definition.

About a / * / # on the desktop. The desktop’s Normal mode has only a selected block id — no character cursor inside the block. So a collapses to i (the textarea’s own caret takes over), and * / # seed the picker with the first few words of the selected block’s text instead of doing a word-under-cursor search. The catalog still ships these chords so muscle memory from the TUI carries over.

Cmd+X / Cmd+C / Cmd+V are mode-aware on the desktop. Inside a block editor (Insert mode, a <textarea> is focused) they are the OS-native text cut / copy / paste — the chords aren’t in the catalog there, so the keystroke reaches the webview untouched. In view mode (Normal, nothing focused) they act on the whole selected block + its subtree: cut marks it to move by id (the paste emits a single Op::Move, so ((blk-…)) refs and backlinks survive — and the target may live on another page, moving the block across pages), copy snapshots it as markdown (the paste duplicates with fresh ids). This is also why run code block moved off Cmd+X to Cmd+Shift+X (view mode): a text-editing app has to let the OS-wide cut win.

Mobile’s “Cut block” mints a fresh id, unlike the desktop’s Cmd/Ctrl+X. The desktop’s block clipboard tags a cut with {kind: "cut", nodeId} and pastes it as a single Op::Move, so the block keeps its identity and every ((blk-…)) ref to it stays valid. Mobile’s long-press “Cut block” instead renders the subtree to markdown and deletes the source in one round-trip, then pastes it back via the same fresh-id path its “Copy block” already uses — a ((blk-…)) ref pointing at the cut block goes stale across the round-trip. Use “Copy block ref” first if something else in the workspace links to the block you’re about to cut.

Cmd/Ctrl+Shift+Enter works without vim mode. Unlike o, the chord is not vim-gated: with no textarea focused the desktop falls into Normal dispatch regardless of the vim_mode setting, so every user can append a block from view mode. Inside a block editor the same chord commits the current edit first (Insert-mode CommitAndContinue). Both Cmd+Shift+Enter (macOS) and Ctrl+Shift+Enter (Windows / Linux) are bound in each mode.

Cursor inside a block (Normal)

These rely on a character cursor inside the selected block. The TUI ships it natively; the desktop has only a selected block id, so the char-cursor ops surface a status-line nudge instead of firing.

Insert mode (text editing)

Visual mode (range)

TUI + desktop; mobile has no Visual equivalent yet.

On the desktop, Shift+↑ / Shift+↓ start (and keep growing) a contiguous selection without vim mode — the non-vim multi-select entry. It flips the client into Visual and pops a floating batch toolbar (N selected + Indent / Outdent / Move up / Move down / Delete / Done) so the range ops are reachable by mouse; the toolbar fires the same actions the chords do. Only the toolbar’s Delete confirms before erasing a range that contains nested children; the keyboard delete (d / x / Delete / Backspace) and the TUI delete without a prompt, matching vim.

Page operations

g d (Normal mode, “go delete”) is the canonical chord for page deletion. It lives in the shared outl-shortcuts catalog, same g<action> family as g j (today) / g x (execute) / g p (properties). The chord deletes the focused page (sidebar-highlighted row when the sidebar has focus on the TUI, otherwise the current page). Each client confirms before invoking outl_actions::page::delete. Journals are refused everywhere. Clients also expose the action through their native page-list affordance.

The desktop routes g d through the same DeletePage handler in action-handlers.ts (same window.confirm + deletePage(slug) flow as the × button). Mobile has no keyboard surface. Long-press in the page switcher remains the only trigger on touch devices.

Reminders (remind::)

Authoring a reminder and inspecting the schedule are chorded on every client; delivering it is per-OS and never a chord. Every client delivers, the TUI included (an OSC 9 notification plus a toast, on its event-loop tick). What the TUI can’t do is deliver while it’s closed, since a terminal session has no background presence — see reminders.md.

Why g n in the TUI and not Ctrl+R? Ctrl+R is already Redo in Normal mode, and a terminal cannot distinguish Ctrl+R from Ctrl+Shift+R. The g family (g j, g x, g d) is the honest home for it there; only the desktop takes the Cmd/Ctrl+Shift+R spelling. Ctrl+R on the desktop likewise stays Redo on Linux / Windows, which is why authoring is Cmd+R only.

Snoozing writes Op::SnoozeRemind, so it converges: silencing a nag on the phone silences the same block on the laptop.

Properties (key:: value)

remind:: above is one property with its own chords; this is the generic door. Creating the first property on a block used to be impossible in either GUI client — you could edit a chip that already existed and nothing more (issue #13).

The key field completes from the workspace’s own key catalogue (outl_actions::known_keys), most-used first, skipping keys the block already carries. Deleting and “empty the value” are the same backend call — the × exists because a gesture nobody can see is not an affordance.

The TUI gets an overlay rather than a form. It is modal and vim, so tabbing between a key field and a value field fights the mode: Tab there means complete, and Enter is what advances key → value → save. /prop and /prop-page stay for muscle memory; the overlay is for when you don’t remember the key.

g p used to mean “pin”. The pinned:: toggle moved to g P (/pin is unchanged). Pinning is a once-per-page act with a second door already; editing properties is a daily one — and pinned:: is itself one of the page properties g p now edits.

Overlays (picker, palette, settings, help)

The picker (Cmd+P / Ctrl+P) fuzzy-matches pages and journals together; type a date in ISO (2026-06-04) or natural (today, yesterday) to jump.

Where each chord lives in the code

A chord change is a single line in defaults.rs plus, if the action is new, a row in action.rs and a handler in each client. See crates/outl-shortcuts/CLAUDE.md for the full add-a-binding checklist.

Help overlay vs. this doc

In the TUI, press ? (Normal mode) to see the live chord table baked into the binary — it’s generated from the same default_bindings() table this doc describes. In the desktop, Cmd+/ opens the same overlay. If you need to look something up while typing, the in-app overlay is faster than this page.

This doc exists so a contributor (or a user shopping for outl) can see every shortcut without launching the app.