Skip to content

Fix(editor): arrow keys navigate the @, / and [[ menus again - #707

Merged
adibhanna merged 4 commits into
ZenNotes:mainfrom
ArditZubaku:fix/completion-arrow-keys
Sep 4, 2026
Merged

Fix(editor): arrow keys navigate the @, / and [[ menus again#707
adibhanna merged 4 commits into
ZenNotes:mainfrom
ArditZubaku:fix/completion-arrow-keys

Conversation

@ArditZubaku

@ArditZubaku ArditZubaku commented Aug 30, 2026

Copy link
Copy Markdown
Contributor

What

Arrow keys navigate an open completion menu again — the @ date/note suggestions, the / slash menu, the [[ reference picker and the callout [! type picker. Before this, ↑/↓ moved the caret instead, and the caret move closed the menu, so the only way to pick an item was Ctrl+N/Ctrl+P.

Why it broke

autocompletion({ defaultKeymap: false }) skips the stock completion keymap so mac AltGr-style layouts keep their Alt-`/Alt-i characters. The filtered replacement (completionKeymapForEditor) was re-added by spreading it into the editor's general keymap.of([...]).

Upstream mounts that keymap at Prec.highest. The spread put it at default precedence and last in the array — and CodeMirror runs same-key bindings in array order (buildKeymap pushes onto binding.run). So defaultKeymap's ArrowUp/ArrowDown (cursorLineUp/cursorLineDown) ran first, returned true, and the completion never saw the key.

EditorPane and PinnedReferencePane spread it last, so they were broken. QuickCaptureApp and TemplateEditorModal happened to spread it first, so they worked — which is why the behaviour differed between the main editor and the Quick Note window.

The fix

A new completionKeymapExtension mounts the same filtered bindings at Prec.highest, matching what @codemirror/autocomplete does for its own keymap. All four editors mount it next to completionNavKeymap instead of inlining the spread, which removes the ordering trap for future edits.

No behaviour change for the AltGr fix — the two mac chords stay filtered out.

Testing

  • New cm-completion-nav-arrows.test.ts: ↓↓↑ moves the highlighted option, the menu stays open and the caret does not move; with no menu open the arrows fall through to the next binding.
  • Verified the old wiring fails that test and the new wiring passes.
  • npm run typecheck, npm run test:run (1827 passed) and npm run build all pass locally on Node 22.

Before / After

Before — ↓ moves the caret and the @ menu closes.

before.mov

After — ↓/↑ move the highlighted item, the menu stays open.

after.mov

@ArditZubaku
ArditZubaku requested a review from adibhanna as a code owner August 30, 2026 22:31
@ArditZubaku
ArditZubaku force-pushed the fix/completion-arrow-keys branch from 105bf73 to 6d41889 Compare September 3, 2026 13:10
adibhanna added a commit that referenced this pull request Sep 4, 2026
Follow-up to #707 for #739. A reader who searches the manual for "wikilink"
found nothing about the picker because both docs surfaces called it "the
[[ reference picker" and never said how to move through it; the picker's
own footer only mentioned the display-text and exact-path syntax. The
in-app manual and the website now call it the wikilink picker, the
authoring entry lists the movement keys (arrows, Ctrl+J/K, Ctrl+N/P,
Enter, Tab, Esc), and the footer hint leads with them, so the answer is on
the surface the moment the picker opens.

Claude-Session: https://claude.ai/code/session_015HNdWonTE8g6dPY2SkdsRS
@adibhanna

Copy link
Copy Markdown
Contributor

Merged into the v2.45.0 release branch, thank you. Verified over CDP in the built app with Vim on and off: the arrows move the highlight in the [[ picker, it stays open, Enter inserts, and Esc still closes it without leaving insert mode. This also closes #739, whose reporter hit exactly this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants