Respect the default editor and support Neovim in Open in editor

[EmanuelMedinaAraujo]

I use Neovim as my default editor on Omarchy, but the T3 Code desktop app does not offer it in the Open in editor picker. nvim is installed and available at /usr/bin/nvim.

Could T3 Code support opening projects and files in the user's configured default editor, including terminal editors such as Neovim?

The desired behavior is:

• Offer a Default editor option, with a configurable command or support for VISUAL/EDITOR where appropriate.
• Support Neovim through an interactive terminal, either the integrated terminal or a configurable external terminal.
• Open the selected workspace or file, preserving the requested line position when available.

This would let users keep their existing editor preference without having to switch to one of the supported GUI editors.

During triage, the source matching my installed version showed that packages/contracts/src/editor.ts defines a fixed list of editor integrations, with no Neovim entry. The upstream main list checked during triage also omitted Neovim:

t3code/packages/contracts/src/editor.ts

Line 28 in 511d20c

export const EDITORS = [

Environment: T3 Code desktop, 0.0.46-nightly.20261012.3035, Linux x64 / Omarchy.

Workaround: launch nvim manually in the integrated terminal.

No matching proposal surfaced in public web searches, but the duplicate check was incomplete because GitHub API access and direct issue/PR searches were unavailable.

Draft produced by Codex (GPT-6.1 Sol) via t3 triage.

[gadzbi123]

Contribution proposal: open Vim/Neovim in the current thread's terminal

I'd like to contribute the integrated-terminal part of this idea. With nvim installed, opening a referenced file currently means copying its path and starting the editor manually. The useful change would be:

1. Choose Neovim or Vim in the thread's Open picker.
2. Open the workspace, or follow a file reference such as src/example.ts:42:7.
3. Get a fresh terminal tab in that same thread, with the editor at the requested file and position. Quitting the editor returns to its shell.

The editor would run on the environment that owns the files, using its installed executable and normal configuration. This would also serve remote environments without requiring a graphical editor on the host.

Proposed first scope

• Web/Electron thread views; installed vim/nvim on Linux/macOS with supported shells and terminal permission.
• The Open picker, preferred-editor shortcut, and thread file links use the same launch path.
• One fresh terminal per open. Where no usable thread terminal exists, retain the saved preference and use an available existing editor target for that open.
• Windows, native mobile UI, external-terminal selection, arbitrary editor commands, and reuse of an existing Neovim session stay outside this proposal.

Implementation feasibility

A local, unpublished prototype reuses the existing editor preference, permission checks, and project-script/PTY flow. It adds no RPC or terminal configuration system. File paths are passed as environment data rather than inserted into shell text; existing literal filenames take precedence over position suffixes.

Recorded feature checks on upstream base 42da166d13: 190 focused tests passed (2 platform skips), affected-package typechecks passed, and 20 real Neovim PTY cases passed across Bash/Zsh. Those checks precede a subsequent icon-only change. Integrated UI verification, Vim runtime checks, and macOS/Fish coverage remain pending; this is evidence of feasibility, not a claim that the feature is ready to merge. UI verification would explicitly check Escape, :q, file positions, and fresh tabs, including the behavior reported in #6362.

Relationship to existing work

This is the terminal-editor use case identified separately in #1425. It could complement configurable editors in #433; #18661 instead proposes Linux default-editor launching through an external terminal.

Maintainer decision: Would this integrated-thread-terminal scope be welcome as a focused contribution, or would you prefer it implemented through the configurable-editor work? I'll wait for explicit direction/scope approval before opening a PR, per CONTRIBUTING.

Prepared with GPT-6.1-Sol through Codex in T3 Code; the local prototype also includes Claude Code work.