[Feature]: Support custom code editors via VISUAL/EDITOR environment variables

[0pilatos0]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop

Problem or use case

The list of supported editors is hardcoded. When users need a different editor (e.g., WebStorm, #428), it requires a code change. As adoption grows, individual editor requests won't scale.

Proposed solution

Read the VISUAL / EDITOR environment variable and offer it as an additional option in the editor picker — not as a replacement for the current default. The built-in list and its default (Cursor) stay as-is. If the env var points to a known editor, reuse its icon/config. If unknown, show it as a generic "System Editor" option that launches with the directory path as the argument.

Why this matters

Users of less common editors can use t3code without waiting for their editor to be explicitly added. Contributors don't need to maintain an ever-growing editor list.

Smallest useful scope

Read VISUAL (falling back to EDITOR), check if the command is on PATH, and surface it as one extra option in the picker. No settings UI needed.

Alternatives considered

Adding editors one by one to the hardcoded list (current approach, see #428). A dedicated settings UI for custom editors — viable but heavier for what environment variables already solve.

Risks or tradeoffs

Some editors may not follow the convention of accepting a directory path as an argument. The generic fallback can't support editor-specific flags like --goto.

Examples or references

Contribution

• I would be open to helping implement this.