Open a site's folder from one menu instead of a remembered editor

[juanmaguitar]

Why

Opening a site's folder shipped in #158 as a remembered choice: an Open in editor button, a
Show in Finder button, a Change editor button, and a modal picker on first use — four
controls and a modal for one intention. This explores the alternative shape sketched in the issue
thread: one menu that says what it does, listing the applications the folder can be opened in.

The application is what the contributor is actually choosing, and it changes — Finder to look at the
files, an editor to change them. Making it a setting configured once puts the wrong thing in front
of them and then makes them go back to change it.

What changes

One control, on the row under the path it acts on. Open directory in ⌄ opens a menu of the
file manager, every editor detection found, and Other application…. Nothing is remembered: the
application is an argument to editor:open, not a stored preference. That deletes editor:get,
editor:choose, the preferences.editor store entry, the first-run picker modal, and the
stale-remembered-editor failure path — three of the four old buttons go with them.

Deliberately not in it: the "(not installed)" rows from the sketch. Detection in
src/editor-launch.js is a fixed table of absolute install locations, and its own header calls it
"a convenience, not the contract" — it misses JetBrains' versioned install directories and most
Linux packaging. A greyed-out VS Code (not installed) would be a confident lie to anyone whose
install the table does not probe, and #158's standing rule is that nothing here ends at a disabled
button. The menu shows what was found; Other application… is always there, never only as a
fallback.

The security shape changed, and that is the part to review hardest. The renderer now names an
executable, where the path used to come out of the main-side store. So editor:open re-establishes
what it is allowed to launch: matchDetectedEditor re-runs detection and answers with the
detected path, which is what gets spawned — checking one string and launching the caller's string
would not be a check (same reason external-url.js hands the OS its parsed URL). A path detection
did not return is refused as unknown-editor before openSiteInEditor is reached. null still
means the native file dialog, whose result is validated exactly as it was under editor:choose.

The path chip and its copy button are untouched — still the floor under all of it.

How to test this

Platforms: any, but the case-insensitivity of the new check is what differs across them and is
covered by tests that run both branches from one machine (test/editor-launch.test.cjs).

Starting state: the app open on any site, with at least one of VS Code / Cursor / PhpStorm /
Sublime Text / Zed installed in its normal location, and ideally one editor installed somewhere
unusual (a JetBrains Toolbox PhpStorm, or any .app outside /Applications).

1. Look at the site header. Under the path row there is a single Open directory in ⌄ link. The
   old Open in editor / Show in Finder / Change editor buttons are gone, and the path
   chip and its copy button are unchanged.
2. Click it. The menu lists Finder (or File Explorer), then each editor found on this
   machine by name, then Other application…. No row is greyed out, and no row claims something
   is "not installed".
3. Choose Finder. The folder opens in the file manager.
4. Reopen the menu and choose an editor. That editor opens on the folder. Reopen the menu: it looks
   exactly as it did — nothing was remembered, no "Change editor" appeared, the chosen one is not
   marked.
5. Choose Other application… and press Escape / Cancel in the dialog. Nothing opens and no
   error appears — dismissing a dialog is an answer, not a failure.
6. Choose Other application… again and point it at the editor installed somewhere the menu did
   not list. It opens, and it is still not remembered.
7. Choose Other application… and point it at something that is not an application (a .txt, or
   any document). A yellow notice appears under the path saying it is not an application this app
   can open a folder in, with a Choose application… button that reopens the dialog.
8. Open the ⋯ More menu at the top right. Copy path and Show in Finder are still there;
   Open in editor is not — that lives in the new menu now.

What must not have happened:

• No remembered editor anywhere: no button that says "Open in Cursor", no "Change editor", no picker
  on first use. If any of those appear, a code path from Open a site's code without leaving the app #158 survived.
• No dead end. Every menu row does something, and every failure leaves a visible notice with a way
  forward. A row that opens nothing and says nothing is the one outcome this feature may not
  produce.
• Nothing writes to preferences.editor any more. An existing user's stored editor is left inert in
  settings.json — it must not be read, and their sites and contributor details must be untouched.

Not testable by hand here: the Windows and Linux branches of the launchable-path and
case-sensitivity checks. Those are exercised by injection in test/editor-launch.test.cjs rather
than skipped, and I verified both new checks fail the suite when the logic is removed.

Risks and limitations

• One extra click per open, forever. The remembered-editor button was one click; this is two.
  That is the trade this shape makes, and it is the main thing to decide before merging.
• Self-review found 3 [fix here] · 1 [follow-up] — all 3 fixed, 1 deferred. Detail in the
  collapsed block below.
• The menu re-runs detection on each open rather than caching it, so an editor installed while the
  app is running appears next time. That is ~10–20 stats per open, all async, off the main
  thread's critical path.
• Not done: keyboard-driven verification of the popover on Windows. The menu is
  Dropdown + MenuGroup/MenuItem from @wordpress/components, the same primitives the sidebar's
  feedback dropdown and the ⋯ menu already use.

Related

Follow-up to #158. Explores the alternative UI proposed for it.

---

Design decisions and alternatives considered

Greyed-out "not installed" rows — rejected. The sketch showed all five known editors always
listed, disabled when absent. Two problems: it turns the detection table from a shortcut into a
claim about the machine, and the table is knowingly incomplete (its own comment says the picker
covers versioned JetBrains installs "exactly as well"). Someone with PhpStorm installed via the
JetBrains installer would read PHPStorm (not installed) and believe the app. A third option —
dimmed but clickable, opening the dialog prefilled — was also dropped: it makes a row mean two
different things depending on a state the contributor cannot see, and Other application… already
covers it honestly.

Dropping the memory entirely — chosen over "remember, last used on top". Keeping the memory
would have kept editor:get, editor:choose and the stored preference alive to save one click.
Since the menu has to exist anyway, the remembered copy is a second source of truth for the same
answer, plus a failure path (the remembered editor moved) that only exists because something was
remembered. The one click is the price.

Where the menu goes. First on the metadata line beside the created date, then beside the copy
button, and finally on its own row under the path — the folder is what it acts on, so it reads
directly beneath the folder, above everything that acts on the site itself.

matchDetectedEditor returns the candidate, not a boolean. A boolean would let a caller check
one string and spawn another; returning the path detection vouches for makes that mistake
unwritable. It lives in editor-launch.js rather than the handler so the case-sensitivity split has
an injected platform and both branches are testable from one machine — the house pattern.

Review outcome (required — see AGENTS.md)

3 [fix here] · 1 [follow-up] — all 3 fixed, the follow-up deferred.

Fixed:

1. Tests 🟡 — the new allow-list check read process.platform inline, so neither branch of the
   case-sensitivity comparison could be exercised from one machine, and no test passed a
   case-differing path at all: the suite would have stayed green with normalize deleted. Moved the
   check into editor-launch.js as matchDetectedEditor with an injected platform, and added
   three tests covering the macOS, Windows and Linux branches. Verified both new tests fail when the
   logic is removed.
2. Security 🔵 — the handler compared normalize(candidate.path) but then passed target, the
   renderer's own string, to openSiteInEditor. On a case-sensitive volume /applications/Cursor.app
   would pass the comparison while being a different filesystem entry. Now the detected path is what
   is spawned.
3. Architecture 🔵 — the comparison duplicated knownEditorName's normalisation while leaving
   that function without a production caller. Both now live in editor-launch.js; the duplication is
   gone.

Deferred:

4. Architecture 🔵 [follow-up] — the Other application… branch opens the file dialog before
   sitePath is checked against the registry, so a site forgotten in another window would show a
   file browser and only then refuse. The ordering predates this PR (editor:choose had the same
   dialog with no site in hand at all), and fixing it belongs with the registry-staleness handling
   rather than here.

Verified and explicitly not findings: preferences.editor needs no migration (nothing reads it on
either side of the upgrade, and the surviving writer spreads the existing object, so contributor
provenance is preserved); the second detection sweep per open is not a user-visible cost.

Style notes from the same pass, all applied: comments in settings-store.js, main.js and
index.jsx that still described the remembered editor, the editorChoice variable name for a hook
that no longer holds a choice, and 'unknown-editor' as a bare literal rather than a
REFUSAL_REASONS entry.

Implementation notes

• src/editor-launch.js — adds matchDetectedEditor(editorPath, { platform, env, exists }) and
  REFUSAL_REASONS.UNKNOWN_EDITOR. Detection, launchability and the spawn are unchanged; nothing
  here consults PATH, at either end, for the reason the file's header gives.
• src/main.js — editor:get and editor:choose are gone; editor:list drops chosen;
  editor:open takes (sitePath, editorPath | null).
• src/preload.js — getEditor and chooseEditor removed; openInEditor takes the second
  argument.
• src/renderer/index.jsx — useEditorChoice becomes useDetectedEditors (detected + loading, no
  chosen, no remember); the picker modal and the three-button row are deleted; the inline notice
  stays and is now the only place a failure speaks, so it carries Choose application… with it.
• Tests: test/editor-launch.test.cjs gains the three matchDetectedEditor cases;
  test/ipc-wiring.test.cjs swaps the editor:get/editor:choose wiring tests for the refusal and
  file-dialog paths. 419 pass, lint clean.

Screenshots or recording

The menu, open, on a site with four applications found. Everything the folder can be opened in,
in one list, with Other application… always at the end — no row disabled, nothing claiming to know
what is not installed:

Closed, the resting state: one link directly under the path it acts on, where three buttons and
a "Change editor" used to be:

Both captured from the running app on macOS through webContents.capturePage(), with the menu
opened by a real click rather than a mock.