Decide whether the :e picker and the Ctrl+B explorer should be one experience

[flyingrobots]

Raised as an open question.

There are two ways to reach a file and they behave differently:

• : then e gives an inline list in the command line, with its own preview behaviour
• Ctrl+B gives the file explorer drawer, with its own navigation

Both browse the filesystem and both end in "open this file". They currently disagree on navigation keys, on preview, and on presentation.

The question

Should these converge on one interaction, or is the difference legitimate — a fast path for typing a path versus a browsing surface for exploring?

Worth weighing

• Several open issues (Arrow keys do not navigate the Ctrl+B file explorer #311, File explorer selection should wrap around at both ends #312, Clicking a file in the explorer should open it #313, Mouse wheel should scroll the active viewport #314, Highlighting a file in the picker overwrites the open document title #315) describe fixes that would otherwise be implemented twice, once per surface
• vi itself keeps :e and a file explorer as distinct things, so divergence is not automatically wrong
• If they stay separate, the shared parts (navigation keys, wrap behaviour, preview policy, open semantics) should still be one implementation used twice

Acceptance

A recorded decision: converge, or stay separate with a named shared core.

[flyingrobots]

Recommending the split with a shared core, and reporting what is actually shared today versus still duplicated.

Recommendation: stay separate, share the primitives

They express different intents. :e is "I know what I want, let me type it"; Ctrl+B is "show me what is here". Collapsing them makes the typing path slower and the browsing path more modal, and vi keeps them distinct for the same reason.

Every difference actually hit in practice — arrow keys working in one, wrap behaviour, preview presentation — was accidental divergence, not design.

What is now shared

Work on #311, #312, #313, #314 and #322 produced three primitives rather than per-surface fixes:

• workspaceDrawerHasFocus (focused-pane-key-bindings.ts) — one predicate for "a drawer owns this input", used by both the key path and the pointer path so they cannot disagree about who receives an event
• wrapIndex (src/app/list-index.ts) — cycling selection movement
• listScrollOffset (workspace/viewport.ts) — the visible window, consumed by both the renderer and pointer hit-testing so a click always resolves to the entry actually drawn

While doing this I found wrapIndex had been implemented twice — a private copy in title-scene-preview-session.ts predating the branch, and mine. Consolidated; that duplication is exactly the failure mode this issue exists to prevent, and I had just contributed to it.

What is still not shared

The :e picker does not use any of them. Its key bindings carry no selectedIndex, wrapIndex or clampIndex; it runs an entirely separate completion mechanism (commandLineFilePreview* state in command-line-key-bindings.ts). So the fixes on this branch improved the Ctrl+B explorer only, and :e still has its own navigation semantics.

That is the concrete remaining work for this issue: route the :e completion list through the same three primitives, so wrap, arrow keys and hit-testing behave identically without merging the two surfaces.

Suggested acceptance

• :e completion navigation uses wrapIndex and honours the same key set
• Preview policy is one decision applied twice, not two implementations
• A spec exercises both surfaces against the same navigation expectations