Ask which editor a changed file opens in, or use the one chosen in Settings by ryanwelcher · Pull Request #753 · WordPress/contributor-toolkit

ryanwelcher · 2026-11-10T17:39:37Z

Why

Clicking a file under "Changed files" opened it in the first editor the app detected, which is Visual Studio Code wherever it is installed. A contributor who uses Cursor, PhpStorm or anything else had no way to change that. Reported at WordCamp Canada Contributor Day (#738).

What changes

Settings → General → Editor has a new Open changed files in choice. It lists the editors the app detects plus Ask each time, which is the default. The choice is stored as the editor's id from the detection table (vscode, cursor, …), not a path, so editor:open still checks every launch against a fresh detection.
A click on a changed file:
1. An editor is chosen and still detected: opens in it.
2. Otherwise, at least one editor detected: a menu beside the file asks. It offers the same items as the site menu's "Open in" ("Other application…", then each detected editor), through the same openInItems.
3. No editor detected: shows the file in the file manager, as before.
An editor chosen and uninstalled since counts as no choice. Settings still shows it, by its name.

Not in this PR: the site menu's "Open in" is unchanged, since it already names an application on every open. An application picked through "Other application…" cannot be saved as the setting, because the setting holds detection ids only. "Remember my choice" in the menu was left out on purpose: Settings is the one place to stop being asked.

How to test this

Platforms: either macOS or Windows. Nothing here touches paths, spawning or signing. Use the Buildkite build for the current head, 588374a.

The journey tests/e2e/journeys/patch-apply.spec.js › "with no editor chosen, a changed file asks which, and the one chosen in the settings is used without asking (#738)" walks this flow with stand-in editors. It fails on the old behaviour (the file opens in Visual Studio Code with no menu). Run it from the repository root with npm run test:e2e:hidden -- tests/e2e/journeys/patch-apply.spec.js -g "#738".

What the journey cannot reach is real editors being detected on a real machine, so the manual pass is about that.

Starting state: a machine with at least two of Visual Studio Code, Cursor, PhpStorm, Sublime Text or Zed installed in their default locations. A site with a ticket linked and a patch applied, so "Changed files" lists at least one file.

Open Settings. Under Editor, Open changed files in reads Ask each time, and its list shows exactly the editors installed. Close Settings.
Click a file under Changed files. A menu opens beside the file with Other application… followed by each installed editor. Nothing opens yet.
Press Escape. The menu closes, nothing opens, and focus is back on the file.
Click the file again and choose an editor that is not Visual Studio Code. The site opens in that editor with the file showing.
In Settings, set Open changed files in to that same editor. Close Settings and click the file. It opens in that editor straight away, with no menu.

What must not have happened:

Visual Studio Code opening at any step where you did not choose it.
At step 5, the menu appearing again.
At step 2, a menu missing an installed editor, or listing one that is not installed.

Risks and limitations

A person with one editor installed is now asked on every click until they choose it in Settings. That is deliberate: the one editor detected may not be the one they use, and the menu's "Other application…" is how they reach an editor the table does not detect.
src/main.js (editor:list, settings:set) and src/settings.cjs change. The stored shape gains one optional key, preferences.editor, so no migration is needed.
The Logs translation journey in tests/e2e/journeys/i18n.spec.js fails locally on this branch and also on trunk without these changes (a strict-mode locator matching two .log-pane-note elements). It is not touched here.

Ask rather than pick. The first version fell back to the first editor detected when nothing was chosen. WordPress Studio does the same (getFirstInstalledEditor), and its "System" default really means "the first one in our list". That reproduces this bug for anyone whose editor is not first, so it was dropped.
Use the only editor found without asking was tried and dropped after review. With VS Code installed and an undetected editor in use, the setting could only offer VS Code, so every click still opened VS Code.
A menu beside the file, not a dialog. It reuses the site menu's items and needs no new decisions. A dialog with "Remember my choice" was considered and left out as a second way to set the same preference.
An id, not a path. Matches Studio's preferredEditor, and keeps "which applications may the window ask main to launch" exactly what it was: what detection found, plus what a person picked in a native dialog.

Review outcome (required — see AGENTS.md)

3 [fix here] · 0 [follow-up]. All 3 fixed.

🟡 Unset with one editor detected opened that editor, so a person who uses an undetected editor could never avoid VS Code, and "Ask each time" was untrue. Fixed: unset now always asks when any editor is found.
🔵 Branching added in index.jsx: an unreachable no-anchor fallback, and the item-to-openIn mapping repeated for the two menus. Fixed: the anchor is required, and both menus use openInEditorPath in site-menu.cjs, with a test.
🔵 A chosen editor uninstalled since was shown in Settings by its raw id. Fixed: editor:list returns the table's names, and editorItems uses them.

Review: completed. A separate agent context, given only the diff and the review instructions. Covered the uncommitted working tree on base 31976b9 (trunk at the time). Lint clean, npm test 2248 pass / 0 fail.
Since review: the three fixes above, then committed and rebased onto trunk dc7cfba (two commits overlap in src/main.js and tests/unit/ipc-wiring.test.cjs, rebased cleanly). Head 588374a. The fixes were checked by the author, not re-reviewed by a fresh context. Lint clean, npm test 2249 pass / 0 fail, and the patch-apply, pr-checkout, settings and site-header journeys pass (36).

Implementation notes

fileOpenTarget in src/renderer/affected-files.cjs decides editor / choose / reveal.
OpenFileInMenu in src/renderer/components/site-header-actions.jsx is anchored to the file's button and returns focus to it on close.
The setting is editor in src/settings.cjs. settings:set accepts an id that editorCandidates has for the current platform.
The setting's dropdown is EditorControl in settings-dialog.jsx, and its entries come from editorItems in settings-view.cjs.
Journeys that clicked a changed file with one stand-in editor (patch-apply, pr-checkout) now choose it from the menu.

Screenshots or recording

Not captured yet: the menu beside a changed file and the new Settings control are both visible changes. To be added from the Buildkite build.

🤖 Generated with Claude Code

…ttings A file under "Changed files" opened in the first editor detection found, which is Visual Studio Code wherever it is installed. Settings now has an "Open changed files in" choice, kept as the editor's id; with none chosen, or one uninstalled since, a menu beside the file asks which application to use, offering what the site menu's "Open in" does. Fixes #738.

coderabbitai · 2026-11-10T17:39:46Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration

Source mode: Auto
Repository: WordPress/contributor-toolkit
Branch: fix/738-changed-files-always-open-in-vs-code
File: .coderabbit.yaml
Commit: 49a7096
Layers: Repository YAML
Review profile: CHILL
Plan: Advanced
Run ID: b3e19234-ec0b-456c-a81b-db1bc280c6f0

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

Trigger review

Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

Copilot

🟡 Changes recommended

A pending editor lookup can open the previous site's chooser and file after a site switch, while Settings silently treats editor-detection failures as empty results.

2 open issues

What changed in this PR

Adds a preferred-editor setting for Changed files, addressing #738 without changing the site menu’s existing “Open in” behavior.

Changes:

Stores and validates an optional editor ID in Settings.
Opens files in the chosen editor, asks when none is available, or reveals them in the file manager when no editors are detected.
Adds unit and journey coverage for editor selection and menu behavior.

Review: 2 [fix here] · 0 [follow-up]. GitHub Copilot completed review of the supplied changes, identified as head 588374a against base dc7cfba. Tests and lint were not run during this review.

File	Description
tests/unit/site-menu.test.cjs	Tests shared editor-menu action mapping.
tests/unit/settings.test.cjs	Tests editor preference defaults and validation.
tests/unit/settings-view.test.cjs	Tests editor dropdown entries and values.
tests/unit/ipc-wiring.test.cjs	Tests preference persistence and editor names.
tests/unit/affected-files.test.cjs	Covers preferred-editor, chooser, and reveal decisions.
tests/e2e/journeys/pr-checkout.spec.js	Updates file-opening flow to choose an editor.
tests/e2e/journeys/patch-apply.spec.js	Exercises chooser dismissal, selection, and saved preference.
src/settings.cjs	Defines and validates the editor preference.
src/renderer/site-menu.cjs	Shares editor-menu action mapping.
src/renderer/settings-view.cjs	Builds editor choices and stored values.
src/renderer/index.jsx	Connects changed-file clicks to preferences and chooser.
src/renderer/components/site-header-actions.jsx	Adds the anchored editor chooser.
src/renderer/components/site-details.jsx	Supplies the clicked file’s menu anchor.
src/renderer/components/settings-dialog.jsx	Adds the editor preference control.
src/renderer/affected-files.cjs	Determines whether to open, ask, or reveal.
src/main.js	Validates editor IDs and exposes editor names.

_{Review effort: Balanced}

-    const target = fileOpenTarget({ editors });
+    const target = fileOpenTarget({ editors, preferred: settings?.editor ?? null });
    if (target.kind === 'editor') await openIn(target.path, relPath);
+    else if (target.kind === 'choose') setFileMenu({ relPath, anchor, editors });


+        setEditors(res?.detected || []);
+        setNames(res?.names || null);
+      })
+      .catch(() => { if (!cancelled) setEditors([]); });


…itors could not be listed A changed file's editor menu no longer opens if the site was left while editor detection answered. Settings now logs a failed editor lookup and says why no editor can be chosen, rather than showing an empty list.

ryanwelcher marked this pull request as ready for review November 10, 2026 17:41

ryanwelcher requested a balanced review from Copilot November 10, 2026 21:00

Copilot started reviewing on behalf of ryanwelcher November 10, 2026 21:00

View session

Copilot AI reviewed Nov 10, 2026

View reviewed changes

ryanwelcher mentioned this pull request Nov 11, 2026

Let a contributor turn on Playground's Xdebug for a site #724

Open

Navigation Menu

Repository navigation

Ask which editor a changed file opens in, or use the one chosen in Settings - #753

Ask which editor a changed file opens in, or use the one chosen in Settings#753
ryanwelcher wants to merge 2 commits into
trunkfrom
fix/738-changed-files-always-open-in-vs-code

ryanwelcher commented Nov 10, 2026

Uh oh!

coderabbitai Bot commented Nov 10, 2026 •

edited

Loading

Review skipped

Uh oh!

Copilot AI left a comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

ryanwelcher commented Nov 10, 2026

Why

What changes

How to test this

Risks and limitations

Related

Uh oh!

coderabbitai Bot commented Nov 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

coderabbitai Bot commented Nov 10, 2026 •

edited

Loading