Le lundi 12 août 2024, 12:52:43 UTC Simon McVittie a écrit : > 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).
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 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". Yes that why I ask for creating shell wrapper. kate for instance could open line column if you pass --line --column 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. Try it. kate for instance return 0 gedit block > > 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. Agreed but here it is only for getting something consistant for desktop user Bastien > > Thanks, > smcv > >
signature.asc
Description: This is a digitally signed message part.
