Le lundi 12 août 2024, 15:17:00 UTC Simon McVittie a écrit : > 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.)
Yes it will work but legacy code exist and run EDITOR therefore sensible-editor is here... SENSIBLE_EDITOR="xdg-open" will work > > 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 Yes so If I do EDITOR= xdg-open" git commit it give some interesting result note that EDITOR="kate -b" git commit will work > > 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. It is the spec of sensible editor fallback gracefully... Bastien > > smcv >
signature.asc
Description: This is a digitally signed message part.
