cmd: stop opening pickers from Ex-mode commands #449

New issue

Closed

opened 2026-04-27 02:06:13 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-04-27 02:06:13 +00:00

Searched existing issues; I did not find an open issue for this. The closest prior work is #391, which introduced the current implicit :Forge pr ci Ex flow.

Problem

The Ex command surface currently has paths that land in picker UI instead of a deterministic command action.

At minimum:

:Forge ci opens current-branch CI history, which is a picker-backed route.
:Forge pr ci resolves the current PR and opens the nested PR checks picker.

That coupling is surprising from Ex-mode. A :Forge ... command should not silently jump into an interactive picker surface. If the operation is fundamentally picker-driven, it should stay on the picker/route/Lua UI surface instead of the Ex commandline.

Proposed solution

Audit the Ex command surface and remove all command paths that dispatch into picker UI, whether directly via pickers.* or indirectly via picker-backed routes.

Specifically:

sever :Forge ci from picker-backed current-branch CI history
sever :Forge pr ci from the PR checks picker
reject unsupported interactive-only Ex flows with a clear warning instead of opening a picker
update docs, completion, and specs so the Ex surface no longer advertises picker-backed behavior

If there is a useful non-interactive Ex replacement for some of these flows, add that explicitly. Otherwise, keep picker access behind mappings, routes, and Lua UI helpers rather than :Forge ....

Alternatives considered

Keep the current behavior and document it better. That still leaves Ex-mode as an unexpected entrypoint into interactive picker UI.
Add more Ex verbs that keep routing into pickers. That increases the coupling instead of removing it.
Keep Lua helpers interactive but remove only the :Forge ... commandline connections. This is acceptable if the repo still wants a programmable interactive surface, but the Ex commandline itself should stay non-picker.

Searched existing issues; I did not find an open issue for this. The closest prior work is #391, which introduced the current implicit `:Forge pr ci` Ex flow. ## Problem The Ex command surface currently has paths that land in picker UI instead of a deterministic command action. At minimum: - `:Forge ci` opens current-branch CI history, which is a picker-backed route. - `:Forge pr ci` resolves the current PR and opens the nested PR checks picker. That coupling is surprising from Ex-mode. A `:Forge ...` command should not silently jump into an interactive picker surface. If the operation is fundamentally picker-driven, it should stay on the picker/route/Lua UI surface instead of the Ex commandline. ## Proposed solution Audit the Ex command surface and remove all command paths that dispatch into picker UI, whether directly via `pickers.*` or indirectly via picker-backed routes. Specifically: - sever `:Forge ci` from picker-backed current-branch CI history - sever `:Forge pr ci` from the PR checks picker - reject unsupported interactive-only Ex flows with a clear warning instead of opening a picker - update docs, completion, and specs so the Ex surface no longer advertises picker-backed behavior If there is a useful non-interactive Ex replacement for some of these flows, add that explicitly. Otherwise, keep picker access behind mappings, routes, and Lua UI helpers rather than `:Forge ...`. ## Alternatives considered - Keep the current behavior and document it better. That still leaves Ex-mode as an unexpected entrypoint into interactive picker UI. - Add more Ex verbs that keep routing into pickers. That increases the coupling instead of removing it. - Keep Lua helpers interactive but remove only the `:Forge ...` commandline connections. This is acceptable if the repo still wants a programmable interactive surface, but the Ex commandline itself should stay non-picker.