[uNyanda]

Summary

Ctrl+P is documented in the Search Notes palette as an alternative to ArrowUp for moving the selection to the previous result. It closes the palette instead.

The same chord closes it from inside the New note form, where the typed name, folder and tags live in component state, so the input is discarded.

global.searchNotes is bound to Mod+P, which resolves to Ctrl+P on Linux and Windows and Cmd+P on macOS. That is the same chord as the Emacs previous-item key that every palette handles for list navigation. Open Notes (Space+O) moves the selection up on it today, which is the behaviour Search Notes is being brought into line with.

Ctrl+N, Ctrl+J and Ctrl+K were unaffected. None of them is a global binding, and that asymmetry is the whole of the report.

Fixes #938.

The change

Removes the toggle from focusPaneHandler in App.tsx. That is the entire fix: a net deletion of eight lines.

The toggle is the sole cause. It sat in a capture-phase listener on window, so it ran before React's delegated root listener, called preventDefault() and stopImmediatePropagation(), and made the palette's own key handler unreachable for as long as the palette was open.

Removing the cause rather than guarding it matters. A guard would have to ask "is this chord wanted by the palette?", which can only answer correctly for the chords that exist today. With the toggle gone, any future global binding that overlaps a palette navigation chord is safe by default.

Nothing is lost by dropping it:

• Escape closes the palette, and the palette's own footer already says so.
• Opening a note and clicking outside both dismiss it.
• The in-app manual describes Mod+P as opening the palette, not toggling it. Neither the keymap description nor the manual ever claimed otherwise, so this aligns the code with the documented contract rather than the reverse.

What stays is the part #510 fixed: the capture-phase registration and the open path are untouched, so Ctrl+P still opens the palette from the editor, and still wins over Vim's Ctrl+P on Linux and Windows.

A short comment at the site explains why it is deliberately not a toggle, and warns against reinstating it above the overlay guard.

Tests

None added, and that is a real gap worth naming.

The regression this guards against is the App.tsx wiring, which no test covers: a reinstated capture-phase intercept would fail nothing. palette-nav.test.ts already pins the chord set, which is what locates the defect precisely, but it cannot see this layer.

Covering it would mean extracting the keydown dispatch out of the useEffect into a testable function. That is a larger refactor than this fix and is left as follow-up work.

Verified manually in the running app: Ctrl+P moves the selection up on the result list and in the New note form's folder and tag lists, the palette no longer toggles, and Open Notes still behaves as before.

[adibhanna]

Thanks @uNyanda, merged into the v2.70.0 release branch (1c94037), so this ships in ZenNotes 2.70.0. Removing the toggle rather than guarding it is the right call, and it now matches Quick capture after #944.

I checked it in the built app on macOS: Cmd+P still opens Search Notes from the editor, Ctrl+N and Ctrl+P move within it, and Escape closes it. The one change macOS users will notice is that Cmd+P inside the open palette no longer closes it; Escape does, as the footer says.

A follow-up commit, 4ac1f63, only fixes the comment's reference: it cited #933 (the New note form footer PR) where the report is #938.