On Mon, 12 Aug 2024 at 08:44:51 -0700, Russ Allbery wrote:
> What this is telling me is that ideally someone should tighten the
> definition of EDITOR in Policy 11.4, which is the specification satisfied
> by sensible-editor, to make it clear that GUI editors with these sorts of
> properties are not valid things to set EDITOR to point to unless flags are
> present to make them behave in a way that satisfies the expectations of
> programs that use EDITOR.
I agree. A backgrounding editor like `gvim` shouldn't be considered to be
a suitable EDITOR (but `gvim -f` would be).
Many other GUI editors behave like `gvim` and not like `gvim -f`, so they
are also perfectly reasonable text editors in general, but not suitable
to be the value of EDITOR; and I suspect quite a lot of GUI editors have
no equivalent of gvim's -f option at all.
The Desktop Entry and MIME Apps specifications leave it unspecified which
way a MIME handler will behave, so anything that is an implementation
of those specifications (like `xdg-open` or `gio open`) is not suitable
as an EDITOR either, because the caller can't know whether the resulting
application is going to wait or not.
> I think the
> Policy language was written in a time where we just assumed there was an
> obvious way for editors to behave that didn't include things like
> backgrounding themselves.
Yes, I think so. Not backgrounding makes a lot of sense for a
line-oriented editor (ed, ex) or a TUI editor (nano, vi) which will
typically occupy the terminal[1] and prevent it from being used for other
purposes *anyway*, but is a lot less obviously desirable for a GUI
editor that will appear elsewhere in a windowing system and can be used
in parallel with the terminal.
smcv
[1] yes I know about screen(1) and similar, but interacting with those
would require special setup that a typical TUI editor doesn't do
