Sensible-editor could now use EDITOR="emacsclient -n -c" and accept
that sh -c accept
My goal is to create a sensible-editor.desktop that will lauch by
default the sensible-editor of choice
For this I plan:
- to allow by alternative mechanism to have an sensible-editor-tty
(may be better wording) sensible-editor-$XDG_CURRENT_DESKTOP
in order to allow default customization
- SENSIBLE_EDITOR is not set, sensible-editor will first try sensible-editor-$XDG_CURRENT_DESKTOP XDG_CURRENT_DESKTOP (if $XDG_CURRENT_DESKTOP
is set) then sensible-editor-tty (using if needed sensible-terminal)
I will also like to allow sensible-editor-STUFF to support +4:3 FILE
command line, so
editor +4:3 somefile.txt will open somefile.txt and if possible go to
line 4 column 3 (and silently ignore if not possible)
Bastien Roucari�s <[email protected]> writes:
Sensible-editor could now use EDITOR="emacsclient -n -c" and accept
that sh -c accept
My goal is to create a sensible-editor.desktop that will lauch by
default the sensible-editor of choice
a) opening a file with the mouse should use gnome's default (which can
change in settings)
I will also like to allow sensible-editor-STUFF to support +4:3 FILE command line, so
editor +4:3 somefile.txt will open somefile.txt and if possible go to
line 4 column 3 (and silently ignore if not possible)
sounds great (and separate to the above), although i wonder how you will
tell whether the underlying editor supports it.
On Mon, 12 Aug 2024 at 12:36:37 +0100, Richard Lewis wrote:
Bastien Roucariès <[email protected]> writes:
Sensible-editor could now use EDITOR="emacsclient -n -c" and accept
that sh -c accept
My goal is to create a sensible-editor.desktop that will lauch by
default the sensible-editor of choice
Echoing what Richard asked: what problem are you aiming to solve with
this? I think designs need to start by stating the problem that they
are solving, instead of jumping directly to a solution.
The way to open any existing file, in a GUI environment, is to look
up the preferred handler for the MIME type of the file (which might
be text/plain or might be something else), and then launch it. This is equally true for text files and non-text files.
This is a general mechanism across all Linux distributions (and other
Unixes such as *BSD), using the freedesktop.org Desktop Entry and
MIME Apps specifications: <https://specifications.freedesktop.org/desktop-entry-spec/latest/>, <https://specifications.freedesktop.org/mime-apps-spec/latest/>.
This is also not specific to text files, and doesn't require creating
one .desktop file per desktop environment per file type (which would
scale poorly); it's a generic mechanism that can work for any MIME type,
and includes a concept of fallbacks like "prefer gnome-text-editor if installed, or try gedit as a second preference, or fall back to any
other editor".
If there's a use-case for which these are insufficient, please talk to
these specifications' upstreams and get consensus on an improvement that
can be adopted upstream by everything that participates in the MIME apps
spec (GLib, Qt, xdg-open, ...), instead of inventing a Debian-specific mechanism that we would have to patch into various packages against upstreams' objections.
a) opening a file with the mouse should use gnome's default (which can
change in settings)
One important point here is that if you have (for example) both GNOME and
KDE Plasma installed on the same machine, and you have not customized settings, then clicking on a text file in a GNOME session will open it in GNOME's default text editor, but clicking on the same text file in a
Plasma session will open it in KDE's default text editor.
This is a desirable feature, particularly for shared machines (for example Gerald and Karen share a computer, Gerald prefers to use GNOME, Karen
prefers to use KDE, and by default they should both get an editor whose appearance and behaviour matches their preferred desktop environment).
I will also like to allow sensible-editor-STUFF to support +4:3 FILE command line, so
editor +4:3 somefile.txt will open somefile.txt and if possible go to line 4 column 3 (and silently ignore if not possible)
sounds great (and separate to the above), although i wonder how you will tell whether the underlying editor supports it.
This convention is somewhat common in (mainly older) CLI-focused, programmer-oriented text editors, but rare in GUI editors, and I'm not
aware of any way to discover programmatically whether a particular editor supports that syntax. In editors that don't support that syntax, the result is not "silently ignore": instead, the most likely result is a confusing erorr message about being unable to open a file named "+4:3".
We shouldn't adopt new features for the benefit of "power users" if they
come at the expense of making it appear to less experienced users that
the overall system is broken, because first impressions matter.
In principle it would be possible to *define* a way to discover whether
an editor supports that syntax - for instance defining a new field in .desktop files, with the default being "assume it's unsupported" - but
if that's done, it should be done in a cross-desktop and cross-distro environment like freedesktop.org, rather than as a "weird Debianism".
I am particularly wary about Debian-specific things in this area because
we already have several examples of identifying a problem, inventing
a Debian-specific solution, investing significant effort over several
years into keeping that solution alive, and eventually deciding that we
have to deprecate it in favour of something cross-distribution (often
against bitter objections from its proponents, who might have got very
used to a particular feature or quirk of the Debian-specific solution).
If we go "upstream first" and help to solve non-Debian-specific problems
for the whole freedesktop ecosystem, then everyone benefits, both inside
and outside Debian.
Thanks,
smcv
Bastien Roucariès <[email protected]> writes:
Sensible-editor could now use EDITOR="emacsclient -n -c" and accept
that sh -c accept
My goal is to create a sensible-editor.desktop that will lauch by
default the sensible-editor of choice
For this I plan:
- to allow by alternative mechanism to have an sensible-editor-tty
(may be better wording) sensible-editor-$XDG_CURRENT_DESKTOP
in order to allow default customization
- SENSIBLE_EDITOR is not set, sensible-editor will first try sensible-editor-$XDG_CURRENT_DESKTOP XDG_CURRENT_DESKTOP (if $XDG_CURRENT_DESKTOP
is set) then sensible-editor-tty (using if needed sensible-terminal)
Can you set out how this affects users
If i am using gnome, i want something pretty simple
a) opening a file with the mouse should use gnome's default (which can
change in settings)
b) but if im in a terminal (even if running in gnome) then i want a
terminal-based editor (based on what i installed)
(b) also means no failures if i get a dpkg "edit conffile" situation
while upgrading -- graphical editors may fail to start, or i might be on
the linux console when dist-upgrading.
i think this all works great today, will it still work with your
proposal? what extra cases are you proposing to support?
I will also like to allow sensible-editor-STUFF to support +4:3 FILE command line, so
editor +4:3 somefile.txt will open somefile.txt and if possible go to
line 4 column 3 (and silently ignore if not possible)
sounds great (and separate to the above), although i wonder how you will
tell whether the underlying editor supports it.
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
I have other problem with unsupported terminal that fail... Even nano does not
fail gracefully on some terminal (try dumb terminal)
kate does not fallback nicely to other editor on linux console for instance.
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
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
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 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.
Simon McVittie <[email protected]> writes:
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
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 don't have any strong opinion on the merits of trying to figure out how
to invoke the editor with the proper flags to make it follow the
expectations of EDITOR if EDITOR is not set, but we do need to be careful
to not invoke programs that would cause, e.g., git commit --amend to immediately exit with no changes to the commit message, and to do that we probably need to write down what those expectations are. 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.
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
b) but if im in a terminal (even if running in gnome) then i want a
terminal-based editor (based on what i installed)
depends for me I prefer to run under emacsclient so you could do
something like
SENSIBLE_EDITOR='if [ -t 0 ]; then sensible-editor-GNOME ; else sensible-editor-tty; fi;'
Bastien Roucariès <[email protected]> writes:Yes but it does not change the need that the editor called should block and be more like ex or vi
b) but if im in a terminal (even if running in gnome) then i want a
terminal-based editor (based on what i installed)
depends for me I prefer to run under emacsclient so you could do
something like
SENSIBLE_EDITOR='if [ -t 0 ]; then sensible-editor-GNOME ; else sensible-editor-tty; fi;'
Couldnt i already put that it in ~/bin/editor and set
EDITOR to that script?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 15:13:07 |
| Calls: | 12,102 |
| Calls today: | 2 |
| Files: | 15,004 |
| Messages: | 6,518,048 |