On Mon, 12 Aug 2024 at 12:36:37 +0100, Richard Lewis wrote: > Bastien Roucariès <ro...@debian.org> 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
