fix(editor): improve external editor (Ctrl-X) UX

[AnanthKini1]

Summary

Fixes three gaps in the external editor (Ctrl-X) feature: cryptic error messages, editors hidden below the fold in /editor, and VS Code-family editors opening their start screen instead of the file.

Details

• Descriptive error messages: editorUtils now throws specific errors (e.g. Editor command 'doesnotexist' was not found in PATH. Install it or use /editor to choose another editor.) instead of emitting a generic label. text-buffer displays the thrown message via getErrorMessage(err). This also eliminates double error reporting.
• Fix infinite loop in /editor dialog: coreEvents.emitFeedback(...) was called directly in the React render body when preferredEditor was set to an unrecognized value, causing an infinite re-render loop. Removed the call; falling back to index 0 ("None") is sufficient since the user is already in the dialog to fix their config.
• Show all editors in /editor picker: With 17 entries and maxItemsToShow=10, items 10–16 (nova through zed) were hidden below the fold with no scroll indicator, making them appear filtered. Fixed by passing maxItemsToShow={editorItems.length}.
• --new-window for VS Code-family editors: cursor --wait file.txt without an active workspace opens Cursor's start screen instead of the file. Added --new-window to editorExtraArgs for vscode, vscodium, cursor, and windsurf, producing cursor --new-window --wait file.txt.
• Documentation: Updated docs/reference/configuration.md to list all 16 supported editor identifiers and document the $VISUAL/$EDITOR fallback behavior.

Related Issues

Closes #21084

How to Validate

1. Set preferredEditor: "notvim" in ~/.gemini/settings.json, press Ctrl-X → one descriptive error naming the unrecognized identifier (not a generic label)
2. Run with EDITOR=doesnotexist, press Ctrl-X → see Editor command 'doesnotexist' was not found in PATH...
3. After either error above, type /editor → dialog opens cleanly with no spam or infinite loop, defaults to "None"
4. Type /editor → all 17 entries (None + 16 editors) visible at once without scrolling
5. Set preferredEditor: "cursor" (with cursor CLI installed via Cmd+Shift+P → "Install 'cursor' command in PATH"), press Ctrl-X → Cursor opens a new window directly on buffer.txt; closing that tab returns the edited text to gemini-cli

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the user experience of the external editor (Ctrl-X) feature by addressing several long-standing usability issues. It provides clearer feedback to users through descriptive error messages, improves the editor selection interface, and ensures a smoother workflow with popular editors like VS Code by opening files in new windows. Additionally, it expands the range of officially supported editors and updates the configuration documentation for better clarity.

Highlights

• Improved Error Messaging: External editor errors now provide specific, user-friendly messages instead of generic ones, guiding users on how to resolve issues related to unrecognized commands or unsupported editors.
• Enhanced Editor Selection UI: The /editor dialog now correctly displays all available editor options without truncation and prevents an infinite re-render loop that previously occurred when an unrecognized editor was configured.
• Better VS Code-family Editor Integration: VS Code, Cursor, and similar editors now open new windows directly to the edited file, avoiding the start screen and improving the workflow.
• Expanded Editor Support & Documentation: The system now recognizes more editors, and the preferredEditor configuration documentation has been thoroughly updated with accepted values, fallback mechanisms, and interactive configuration instructions.

Changelog

• docs/reference/configuration.md
  • Updated documentation for general.preferredEditor to list all supported editors, explain $VISUAL/$EDITOR fallback, and clarify error handling.
• package-lock.json
  • Modified dependency metadata by adding peer: true to several packages, reflecting updated dependency resolution.
• packages/cli/src/ui/components/EditorSettingsDialog.tsx
  • Refactored editor selection logic to prevent an infinite re-render loop when an invalid editor is set.
  • Ensured all editor options are visible in the dialog by setting maxItemsToShow dynamically.
• packages/cli/src/ui/components/shared/text-buffer.ts
  • Integrated getErrorMessage to display more informative error messages from external editor operations.
• packages/cli/src/ui/utils/editorUtils.ts
  • Implemented robust error handling for unrecognized editor types, throwing specific errors.
  • Added support for editor-specific arguments like --new-window for VS Code-family editors.
  • Expanded the list of recognized terminal editors to include emacsclient and micro.
• packages/core/src/utils/editor.test.ts
  • Added comprehensive unit tests for new editor utility functions, including isValidEditorType, getEditorWaitFlag, and getEditorExtraArgs.
  • Updated existing tests to include newly supported editors and their behaviors.
• packages/core/src/utils/editor.ts
  • Extended the internal lists of GUI and terminal editors to include sublimetext, lapce, nova, bbedit, emacsclient, and micro.
  • Introduced functions getEditorWaitFlag and getEditorExtraArgs to handle editor-specific command-line arguments.
  • Updated getDiffCommand logic to support diffs for emacsclient and bbedit.
• schemas/settings.schema.json
  • Enhanced the schema definition for general.preferredEditor with a detailed description, markdown description, and an enumerated list of valid editor identifiers.

Activity

• This pull request addresses and closes issue External editor support: unclear error messages, missing editors, incomplete documentation #21084, which aimed to improve the external editor (Ctrl-X) user experience.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request significantly improves the user experience for the external editor (Ctrl-X) feature by introducing more descriptive error messages, fixing an infinite loop in the /editor dialog, ensuring all editors are visible in the picker, and adding necessary arguments for VS Code-family editors. Documentation and tests have also been updated. However, it introduces or preserves a high-severity command injection vulnerability on Windows due to the openFileInEditor function using shell: true with unquoted arguments. This should be resolved by properly quoting command-line arguments or avoiding shell: true. Furthermore, the new, robust logic for handling editor arguments is only applied when using the preferredEditor setting, not with $VISUAL or $EDITOR environment variables, leading to inconsistent behavior and an incomplete fix for VS Code-family editors.

[alberti42]

Thanks for the PR!

I need to point out that this PR is a duplicate of PR #21090, which has already received its first review.

Can we merge the best from both PR? How should we proceed?

[AnanthKini1]

Thanks for the PR!

I need to point out that this PR is a duplicate of PR #21090, which has already received its first review.

Can we merge the best from both PR? How should we proceed?

Thanks for the heads-up! I definitely don't want to duplicate our efforts. Our PRs do overlap on adding Sublime/Emacs as supported editors and fixing the error message when opening up unsupported editors, but mine also addresses a few extra bugs I found while testing:

• Fixed an infinite re-render loop: coreEvents.emitFeedback was being called inside a React render body, which was causing the CLI to hang or crash when using '/' commands after an error message was displayed.

• Added --new-window support: For the VS Code family (and Cursor), this ensures the editor opens directly to the buffer file instead of a "Welcome" screen.

• Resolved Editor Visibility: I fixed a maxItemsToShow constraint that was leaving out the bottom half of supported editors in the /editor picker.

• Actionable Error Messages: I refactored the error path so the UI displays specific instructions (like "Install command in PATH") instead of a generic message.

• Expanded Editor Support: In addition to Sublime and Emacs, my PR adds first-class support for Lapce, Nova, BBEdit, and Micro.

Let me know how best to proceed! I'm happy to add these additional fixes to your branch or trim my PR to include just these improvements.

[alberti42]

Yes, we should definitely keep your extra fixes and extra editors. I don't want work to be lost. I am not checking it how hard it is to cherry-pick your commits and replay them onto my PR and resolve conflicts. I will now make a quick assessment and report back.

[alberti42]

Hi @AnanthKini1, thanks for the great work on this! Rather than running two competing PRs, I've integrated your commits into my branch. Here's what I did:

1. Rebased both branches on top of the latest upstream main.
2. Your branch had some conflicts with main after the rebase; I resolved them. Mine was already clean.
3. Cherry-picked your 5 commits onto my branch (extra-editors), so your authorship is fully preserved in the git history.
4. The preferredEditor description had already been flagged as too long in a previous review on my PR by jacob314 — we had already shortened it. Your version was even longer, so I restored our shorter version.
5. schemas/settings.schema.json and docs/reference/configuration.md are auto-generated by npm run docs:settings from settingsSchema.ts, so your manual edits get wiped. I fixed this properly by changing preferredEditor to type enum in settingsSchema.ts and adding all the editor identifiers as options; the generator now produces the values list and the enum automatically.

I've also invited you as a collaborator on my fork (you would need to accept it if you agree with the proposal), so you can push directly to the extra-editors branch. That way we can iterate together without having to continuously cherry-pick between PRs. The PR to track is #21090.

[AnanthKini1]

Hi @AnanthKini1, thanks for the great work on this! Rather than running two competing PRs, I've integrated your commits into my branch. Here's what I did:

1. Rebased both branches on top of the latest upstream main.
2. Your branch had some conflicts with main after the rebase; I resolved them. Mine was already clean.
3. Cherry-picked your 5 commits onto my branch (extra-editors), so your authorship is fully preserved in the git history.
4. The preferredEditor description had already been flagged as too long in a previous review on my PR by jacob314 — we had already shortened it. Your version was even longer, so I restored our shorter version.
5. schemas/settings.schema.json and docs/reference/configuration.md are auto-generated by npm run docs:settings from settingsSchema.ts, so your manual edits get wiped. I fixed this properly by changing preferredEditor to type enum in settingsSchema.ts and adding all the editor identifiers as options; the generator now produces the values list and the enum automatically.

I've also invited you as a collaborator on my fork (you would need to accept it if you agree with the proposal), so you can push directly to the extra-editors branch. That way we can iterate together without having to continuously cherry-pick between PRs. The PR to track is #21090.

Hi @alberti42! Thank you so much for merging our work and preserving my authorship, I really appreciate it. I've accepted the invitation to your fork and will keep an eye out for any comments left by maintainers.

[alberti42]

@AnanthKini1 We have received feedback from #21090. I just wanted to give you a heads-up in case you are not tracking it. I will be very busy in the next few days. So if you have time to already take care of some of the comments, it would be great.

[AnanthKini1]

@AnanthKini1 We have received feedback from #21090. I just wanted to give you a heads-up in case you are not tracking it. I will be very busy in the next few days. So if you have time to already take care of some of the comments, it would be great.

Hi @alberti42 ! Yes, just saw the comments--I will address these issues tomorrow.

[alberti42]

Hi Ananth, I did reply to the reviewers' concern on the other branch. Let's see what he thinks of it.

[AnanthKini1]

Hi Ananth, I did reply to the reviewers' concern on the other branch. Let's see what he thinks of it.

Hi Andrea, thank you for addressing the fixes! I apologize for not addressing them earlier, I was overwhelmed with some schoolwork as it is now finals week 🥲. I will be more diligent in fixing concerns earlier in the future.

[alberti42]

Love it. No, you were not slow at all. I was tired of preparing exams (also here we have finals) so I needed a couple of hours thinking of something else, and I had decided to fix what was left to be done.

[cocosheng-g]

Closing this since the #21090 is the latest one.