On Mon, 12 Aug 2024 at 14:23:51 +0000, Bastien Roucariès wrote:
> Yes I want sensible-editor to open kate on kde and gnome-editor on gnome.
> 
> Thinks about running latex and typing e for editing, it should run the 
> desktop editor of choice.
> 
> I do not want to change desktop user choice

This use-case doesn't need a Debian-specific mechanism, because there
are already many implementations of the Desktop Entry and MIME App
specifications, such as:

    xdg-open "$document"                # from xdg-utils
    gio open "$document"                # from libglib2.0-bin

or, ideally, calling into a library in your implementation language
that implements those specifications without needing a CLI layer
in between. (For example `gio open` is basically a CLI wrapper
around g_app_info_launch_default_for_uri_async(), so in C code that
already depends on GLib for some other reason, it's better to call
g_app_info_launch_default_for_uri_async() directly.)

One limitation of this (which is unsolvable in anything based on .desktop
files) is that it's considered equally valid for the handler to daemonize,
run in the background and exit immediately (like `gvim $file`), or to
run "in the foreground" until the user exits, and then exit (like
`gvim -f $file`). So you can't rely on using something like this if
you want your process to block until the user has saved the file and
exited. But that isn't something you can rely on from GUI editors anyway,
because not all GUI editors even have that as a concept - some are
"single-instance" and expect to open all files in one instance of the
editor app.

The approach to this that will work consistently is to launch the handler
asynchronously (in the background), and not attempt to find out whether
it has exited or not. So for example an interactive shell script might
do something like this:

    #!/bin/bash
    # note that disown is a bashism

    xdg-open "$document" &
    disown $!
    echo "Press Enter when you have finished editing $document..."
    read

> I have other problem with unsupported terminal that fail... Even nano does not
> fail gracefully on some terminal (try dumb terminal)

Yes, running a text editor in an environment that is not supported by
that text editor will not work. I don't see why that would be unexpected.

> kate does not fallback nicely to other editor on linux console for instance.

No: falling back from the implementation of some class of application
that you asked for to a different implementation is not behaviour that
I would expect. If you run a GUI file manager like Nautilus or Dolphin
from a Linux virtual console, it doesn't try to "do what you mean"
and run mc instead. Text editors are no different.

    smcv

Reply via email to