Finish vim-style navigation: the search surfaces are the missing half

[bradenr402]

Finish vim-style navigation: the search surfaces are the missing half

The gap

Omarchy already has vim navigation in a good chunk of the shell.
Ui/PanelKeyCatcher.qml:59-70 binds h/j/k/l next to the arrows:

if (event.key === Qt.Key_Down  || event.text === "j") { moveRequested(0, 1);  ... }
if (event.key === Qt.Key_Up    || event.text === "k") { moveRequested(0, -1); ... }
if (event.key === Qt.Key_Right || event.text === "l") { moveRequested(1, 0);  ... }
if (event.key === Qt.Key_Left  || event.text === "h") { moveRequested(-1, 0); ... }

Ten bar panels route through it — network, bluetooth, audio, power, tailscale,
clock, weather, monitor, dropbox, agents. Ui/Dropdown, Ui/MultiSelect and
Ui/SearchableDropdown bind j/k in their popup lists;
Ui/ButtonGroup.qml:86-101 binds h/l.

But four surfaces have no vim navigation at all:

Surface	File	Shape
Menu	plugins/menu/Menu.qml:1074-1116	list
Clipboard	plugins/clipboard/Clipboard.qml:352-397	list
Emojis	plugins/emojis/Emojis.qml:197-231	grid (2-D)
Image picker (themes/backgrounds)	plugins/image-picker/ImagePicker.qml:408-432	horizontal carousel

These are, in my experience, the surfaces people drive from the keyboard most.

Why they were skipped, and why it isn't an oversight

All four are search-as-you-type. Each key handler ends in a catch-all along
these lines (Menu.qml:1113):

} else if (event.text && event.text.length === 1 && event.text.charCodeAt(0) >= 32 ...) {
  root.setFilter(root.filterText + event.text)
}

On these surfaces h, j, k and l are filter characters. You cannot bind
them to motion without breaking type-to-search, which is the primary
interaction. So this is a genuine design conflict, not a missed spot — it needs
a mode discriminator before it can be resolved either way.

Prior art

Several PRs have approached this from different angles and none has landed:

• Add Vim style navigation to Menu, Clipboard, Emoji & Image-Picker #8318 — Ctrl+hjkl across menu, clipboard, emojis, image picker
• Add ctrl-n and ctrl-p menu navigation #7513, Add Ctrl-N and Ctrl-P menu navigation #7042 — Ctrl-N / Ctrl-P in the menu
• Let users rebind the menu's navigation keys #7345, Make the menu's navigation keys configurable #7737 — make the menu's navigation keys configurable/rebindable

#8318 sidesteps the conflict with a Ctrl modifier, which works and is
non-breaking, but leaves the shell in the odd position of having bare hjkl in
panels and Ctrl hjkl in overlays — two different vim idioms depending on which
surface has focus.

Proposal

Add a single opt-in setting that turns the four filter surfaces modal, so bare
hjkl means the same thing everywhere:

"navigation": { "vimMode": false }

Normal mode (the default state when a surface opens, when the flag is on):

Key	Action
h j k l	motion — reusing PanelKeyCatcher's existing moveRequested(dx, dy)
g / G	first / last
Ctrl+D / Ctrl+U	half page
/	enter search
Enter	activate
Esc	close

Search mode: exactly today's behavior — type to filter, arrows navigate,
Enter activates. Esc returns to normal mode keeping the filtered results, so
they can be walked with hjkl; a second Esc clears the filter; a third
closes.

The header needs to show which mode is active, otherwise the modality is
invisible — a leading / on the query while searching, and a short right-aligned
/ search hint while in normal mode, is enough.

Default off. Nothing changes for anyone who does not opt in, and panel
hjkl stays unconditional so no existing behavior regresses.

Implementation sketch

The natural move is to extend PanelKeyCatcher rather than add a second
component — it already emits the right semantic signals (moveRequested,
activateRequested, closeRequested, textKey) and already has a blocked
escape hatch for inline editors. Adding opt-in filterable / filterText /
vimMode properties lets the four surfaces adopt the same component and delete
their hand-rolled Keys.onPressed blocks.

Because moveRequested is already 2-D, the grid and carousel cases fall out for
free: emojis interpret dy as row steps, the image picker ignores it.

Config would be read off shell.shellConfig the way
plugins/services/idle/Service.qml:19 reads idle.lock.

One adjacent inconsistency worth folding in or fixing separately:
Ui/ConfirmDialog.qml:23-35 handles Left/Right but not h/l, unlike
ButtonGroup.

Where I'm coming from

I built this for myself against a local clone of the menu plugin and have been
running it for a bit. The mode model above is what survived contact with actual
use — in particular, keeping the filter alive when leaving search mode turned out
to matter a lot, since narrowing a list and then wanting to walk it is the common
case.

Happy to open a PR if there's interest and if the opt-in-flag shape is the right
one. Wanted to check the direction first rather than add a fifth competing PR to
the four already open on this.

---

Filed by Claude (Anthropic's Claude Opus 5), acting as a coding agent on
behalf of @bradenr402, who reviewed this before it was posted. The research,
prototype and draft above are the agent's work; the decision to open this
discussion, and the design calls in it, are Braden's.