Allow limiting selection to only GUI/CLI options

[CyanBlob]

I'm working on a GUI application, and was hoping to be able to use this crate to allow users to edit some files. However, it seems to be attempting to launch my CLI editor (nvim) despite being launched from a GUI, which unfortunately makes this crate unusable as it is now.

[twilligon]

My goal with this crate is to have behavior similar to Git, which also opens a terminal editor even from a GUI if that is what is set in your EDITOR variable. The hardcoded list of editors is just to provide some sort of fallback in case EDITOR is not set. After all, opening a terminal editor should be better than failing to find an editor to launch at all. I think trying to maintain a blacklist of command-line editors so GUI apps only open GUI editors could be a cat-and-mouse game as I'm sure there are other CLI editors I and edit are not aware of.

The easiest solution is the same as it is for Git: change your default editor to a GUI editor. Many Git tutorials have this as one of the first steps, but I agree that it would be better UX-wise not to have to do this. One workaround if you want this to Just Work for anyone using your GUI app is to set the EDITOR variable upon startup to the path for a GUI editor; then edit should pick it up.

// find the GUI editor of your choice
let gui_editor = "/usr/local/bin/my-editor";
std::env::set_var("EDITOR", gui_editor);
edit::edit("edit me"); // should open my-editor

[ok-nick]

Is it expected for the crate to open the CLI editor in a new terminal window if invoked from a GUI editor?

[MatthewBlanchard]

My goal with this crate is to have behavior similar to Git, which also opens a terminal editor even from a GUI if that is what is set in your EDITOR variable. The hardcoded list of editors is just to provide some sort of fallback in case EDITOR is not set. After all, opening a terminal editor should be better than failing to find an editor to launch at all. I think trying to maintain a blacklist of command-line editors so GUI apps only open GUI editors could be a cat-and-mouse game as I'm sure there are other CLI editors I and edit are not aware of.

The easiest solution is the same as it is for Git: change your default editor to a GUI editor. Many Git tutorials have this as one of the first steps, but I agree that it would be better UX-wise not to have to do this. One workaround if you want this to Just Work for anyone using your GUI app is to set the EDITOR variable upon startup to the path for a GUI editor; then edit should pick it up.

// find the GUI editor of your choice
let gui_editor = "/usr/local/bin/my-editor";
std::env::set_var("EDITOR", gui_editor);
edit::edit("edit me"); // should open my-editor

Instead of trying to provide a hardcoded blacklist why not provide the tools for the library consumer to do this themselves? Something like get_editors() that returns a list of all present editors the library tracks, and then an edit_with_editor() that accepts the names returned by get_editors? This would put the figuring out if it's gui or cli part on the crate consumer, but at least give them the tools to do it.

It'd also be nice for GUI tools to be able to present a list of editors found and choose a default there, since I would rather not have EDITOR set to vscode, but there are things I would rather have open in vscode.