Problem
AionCore's shell module currently opens workspace folders by running code . (VS Code). Users who prefer other editors (Zed, Fleet, VSCodium, etc.) cannot change this without modifying the source.
Use case
I use Zed as my daily driver. The shell::open_workspace flow hardcodes code, which means every "open in editor" action either fails silently or opens the wrong editor.
Prior work
I had a proof-of-concept in PR #685 (now closed) that introduced an EditorCommand enum and shell-level dispatch (zed . when Zed is installed, fallback to code .). The approach was:
- Add a
ShellCommand::OpenEditor variant to crates/aionui-api-types/src/shell.rs
- Detect installed editors at the shell service layer
- Dispatch to the right CLI
Question
Would the project accept making the editor CLI configurable — either through auto-detection (my approach) or a user-facing setting? Happy to adapt the implementation to match the team's preferred pattern.
Problem
AionCore's shell module currently opens workspace folders by running
code .(VS Code). Users who prefer other editors (Zed, Fleet, VSCodium, etc.) cannot change this without modifying the source.Use case
I use Zed as my daily driver. The
shell::open_workspaceflow hardcodescode, which means every "open in editor" action either fails silently or opens the wrong editor.Prior work
I had a proof-of-concept in PR #685 (now closed) that introduced an
EditorCommandenum and shell-level dispatch (zed .when Zed is installed, fallback tocode .). The approach was:ShellCommand::OpenEditorvariant tocrates/aionui-api-types/src/shell.rsQuestion
Would the project accept making the editor CLI configurable — either through auto-detection (my approach) or a user-facing setting? Happy to adapt the implementation to match the team's preferred pattern.