Context menu as minibuffer

The right-click menu is already a command list with a header, groups, and drill-downs — it is a minibuffer that forgot how to be typed into. This makes them the same widget: right-click sets the scope, the command-line does the rest. Nothing is disabled; the menu just stops being a popup.

Live — right-click a block

try all three; esc closes

treatment type to filter · ↑↓ ⏎ → drill · ⌫ pop scope

home·dayweekmonthfind /go SPCdo :·context

←2026-08-15→{filter}

-- NORMAL --? for keys

Do:filter…esc

↑↓ nav ⏎ run → into ⌫ back scoped to the block at point

What changed in B: the popup's header line becomes the scope chip, its groups stay groups, its submenus (Add block…, Dates…, Tags…) become → drill-downs that push another chip, and the same list is what : already opens — only unscoped. One list, one renderer, one keymap, no overflow math.

The three treatments

todayA · anchored popup

Grows past the viewport the moment a block has more than ~10 verbs, and the header wraps to two lines on a long block. Every fix is geometry work: flip-up, scroll, virtualize, submenu collision.

can't be filtered by typing
keyboard reaches it only via a separate path
second command surface to design forever

recommendB · right-click scopes the minibuffer

Right-click = "move point here and open the command-line scoped to it". Identical to : with a scope chip pre-filled — which is exactly what Modal Navigation §8 already describes.

never overflows: fixed 60vh dock, scrolls
typing filters 40 verbs down to one
key hints sit next to every row, so the menu teaches the chords
mouse and keyboard converge on one list

fallbackC · 4-item stub, rest spills down

Keeps proximity for the two or three verbs a mouse user actually wants, with more… ⇥ dropping into the same scoped minibuffer.

hedges if B tests as "where did my menu go?"
but reintroduces the second surface, and the stub's 4 slots become a permanent argument

Why it won't confuse (and where it might)

The block still visibly reacts. Right-click pins the rose point-rule on the block before the minibuffer rises — same affordance the desk cursor already uses. The scope chip repeats the block's title. Nothing is "somewhere else"; the target is lit and named.

Distance is the real cost. The pointer travels to the bottom of the window. That is the one honest loss vs. A — and it is paid back the instant the user types two letters instead of hunting a 14-row list. For a mouse-only user it's a wash; for anyone who ever touches the keyboard it's a clear win.

Don't swallow the browser menu. ⇧ + right-click passes through to native (copy / inspect / spellcheck). Right-click inside an active text selection should still offer text verbs — put copy, cut, summon selection at the top of the scoped list rather than forking a surface.

Long-press = right-click on touch, so mobile gets the same scoped minibuffer it already has as chrome. That's a bonus A never had.

Open question — should right-click also move the desk cursor permanently, or scope the command-line without disturbing point (menu closes, cursor stays where it was)? Vim-consistency says move it; undo-ability says don't.