I found myself today using GUI emacs 27.1, and was surprised that it wasn't at all integrated with the (debian) linux desktop. It doesn't seem like a big deal to make part of a standard install, but in the context of 'trying to make emacs easier' it would go a long way. I never know when I post on this list whether something has already been either done or flat-out rejected sometime in the past, oh, 30 years?, but here's a simple two-step proposal to accomplish the type of integration I think *ALL* newcomers would expect when installing GUI emacs (ie. when one selects file(s) in a file manager, they are opened in Emacs). Step 1: New file: /usr/share/applications/emacsclient.desktop #+begin_src conf [Desktop Entry] Name=Emacsclient GenericName=Connect to an Emacs server X-GNOME-FullName=Connect to an Emacs server Encoding=UTF-8 Version=1.0 Comment=Connect to an Emacs server using emacsclient NoDisplay=false Exec=\emacsclient -c --alternate-editor="" --eval "(pick-a-suitable-name \"%F\")" Terminal=false X-MultipleArgs=false Type=Application Icon=emacs Categories=Office;Development StartupWMClass=Emacs StartupNotify=true # MimeType= #+end_src Step 2: New function: pick-a-suitable-name #+BEGIN_SRC emacs-lisp (defun pick-a-suitable-name (&optional files) "Integrate GUI Emacs with XFreeDesktop" ;; Do optional 'stuff' ;; Do other optional 'stuff' (dolist (file (split-string (substring files 1 -1) "' '")) (find-file file)) ;; Do more optional 'stuff' ) #+END_SRC I'll cross-post this on the debian list for their own independent consideration. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
> Step 1: New file: /usr/share/applications/emacsclient.desktop
> #+begin_src conf
> [Desktop Entry]
> Name=Emacsclient
> GenericName=Connect to an Emacs server
> X-GNOME-FullName=Connect to an Emacs server
> Encoding=UTF-8
> Version=1.0
> Comment=Connect to an Emacs server using emacsclient
> NoDisplay=false
> Exec=\emacsclient -c --alternate-editor="" --eval "(pick-a-suitable-name \"%F\")"
> Terminal=false
> X-MultipleArgs=false
> Type=Application
> Icon=emacs
> Categories=Office;Development
> StartupWMClass=Emacs
> StartupNotify=true
> # MimeType=
> #+end_src
Oh, yes, please a `emacsclient.desktop` would be very welcome (I
actually expected the Debian packagers to provide it ;-).
I don't know what the lines above really do, tho, so I can't judge
whether they're the best choice. I do know the
\emacsclient -c --alternate-editor="" --eval "(pick-a-suitable-name \"%F\")"
looks odd. How is this %F defined (e.g. what is it expanded to when the
file you try to open contains a space or a quote character in its name)?
I expected it should be more like:
\emacsclient -c --alternate-editor="" %F
Can you explain how your `pick-a-suitable-name` differs from that?
Stefan
> Date: Thu, 13 May 2021 23:18:25 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
>
> I found myself today using GUI emacs 27.1, and was surprised that it
> wasn't at all integrated with the (debian) linux desktop. It doesn't
> seem like a big deal to make part of a standard install, but in the
> context of 'trying to make emacs easier' it would go a long way. I never
> know when I post on this list whether something has already been either
> done or flat-out rejected sometime in the past, oh, 30 years?, but
> here's a simple two-step proposal to accomplish the type of integration
> I think *ALL* newcomers would expect when installing GUI emacs (ie. when
> one selects file(s) in a file manager, they are opened in Emacs).
>
> Step 1: New file: /usr/share/applications/emacsclient.desktop
The master branch has etc/emacsclient.desktop, which looks similar to
what you want. Can you try that and provide feedback? If that file
is OK, then Emacs 28 will have this bundled, and the problem is
solved.
Thanks.
On Fri, May 14 2021, Eli Zaretskii wrote:
>> Step 1: New file: /usr/share/applications/emacsclient.desktop
>
> The master branch has etc/emacsclient.desktop, which looks similar to
> what you want. Can you try that and provide feedback? If that file
> is OK, then Emacs 28 will have this bundled, and the problem is
> solved.
I compile Emacs from source, always from the latest release branch, so currently
emacs-27, and I get an emacs.desktop installed on my system when doing make
install. I even need to exclude it from my xstow.ini because I had to customise
it and I don't want it overwritten every time I pull the latest commits and
recompile Emacs.
So from my point of view, this is already working on Emacs 27...
--
Joost Kremers
Life has its moments
> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Fri, 14 May 2021 09:20:10 +0200
>
>
> On Fri, May 14 2021, Eli Zaretskii wrote:
> >> Step 1: New file: /usr/share/applications/emacsclient.desktop
> >
> > The master branch has etc/emacsclient.desktop, which looks similar to
> > what you want. Can you try that and provide feedback? If that file
> > is OK, then Emacs 28 will have this bundled, and the problem is
> > solved.
>
> I compile Emacs from source, always from the latest release branch, so currently
> emacs-27, and I get an emacs.desktop installed on my system when doing make
> install. I even need to exclude it from my xstow.ini because I had to customise
> it and I don't want it overwritten every time I pull the latest commits and
> recompile Emacs.
>
> So from my point of view, this is already working on Emacs 27...
Does emacs.desktop work for emacsclient invocations as well? If so,
why did we add emacsclient.desktop on master? (I know nothing about
GNOME desktop and its use protocols.)
On Fri, May 14 2021, Eli Zaretskii wrote:
>> I compile Emacs from source, always from the latest release branch, so
>> currently emacs-27, and I get an emacs.desktop installed on my system when
>> doing make install. I even need to exclude it from my xstow.ini because I had
>> to customise it and I don't want it overwritten every time I pull the latest
>> commits and recompile Emacs.
>>
>> So from my point of view, this is already working on Emacs 27...
>
> Does emacs.desktop work for emacsclient invocations as well? If so,
> why did we add emacsclient.desktop on master? (I know nothing about
> GNOME desktop and its use protocols.)
I don't know, and I don't have a clue how to go about testing that. AFAIK a
.desktop file allows you to put a launcher in the dock and in the Applications
menu of your GUI and that's it.
--
Joost Kremers
Life has its moments
On Fri, 14 May 2021 at 14:55, Joost Kremers <joostkremers@fastmail.fm> wrote: > On Fri, May 14 2021, Eli Zaretskii wrote: > > > Does emacs.desktop work for emacsclient invocations as well? If so, > > why did we add emacsclient.desktop on master? (I know nothing about > > GNOME desktop and its use protocols.) > > I don't know, and I don't have a clue how to go about testing that. AFAIK a > .desktop file allows you to put a launcher in the dock and in the Applications > menu of your GUI and that's it. No, that’s not (only) it. A .desktop file: * Puts a launcher in the Applications menu so you can launch the application. * Optionally, associates an application with a set of MIME types so you can open documents with that application from your file manager, mail client, and other applications. * Optionally, associates an application with an URL scheme so you can open URLs in that application. A simple .desktop file only has a single command line defined. It is also possible to define multiple actions with different command lines and supporting launcher GUIs will expose those actions to the user, but etc/emacs.desktop in current master does not use this capability. https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html
> I don't know, and I don't have a clue how to go about testing that. AFAIK a
> .desktop file allows you to put a launcher in the dock and in the Applications
> menu of your GUI and that's it.
It's also necessary to have a `emacsclient.desktop` file in order to be
able to select `emacsclient` as the application to associate with
a particular mime-type in Firefox (it used to be possible to just give
the full filename of the executable, but it's more complicated now).
Stefan
On 2021-05-13 23:46, Stefan Monnier wrote:
> I expected it should be more like:
>
> \emacsclient -c --alternate-editor="" %F
>
> Can you explain how your `pick-a-suitable-name` differs from that?
When selecting three files 'foo', 'bar', 'baz', my Emacs was receiving a
single parameter string "'foo' 'bar' 'baz'" instead of three separate
parameters. I'm not sure why, because in response to your email I
re-tested the original and am not reproducing the error.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
On 2021-05-14 09:45, Eli Zaretskii wrote:
> The master branch has etc/emacsclient.desktop, which looks similar to
> what you want. Can you try that and provide feedback? If that file
> is OK, then Emacs 28 will have this bundled, and the problem is
> solved.
Works great. Problem solved.
But:
The product should be clearly distinguish-able from the product of other
emacs-related desktop files. Specificallly, the 'comment' and/or 'generic
name' should reflect that it will connect to a pre-existing emacs server
if one exists.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
> Date: Sat, 15 May 2021 23:33:57 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: emacs-devel@gnu.org
>
> The product should be clearly distinguish-able from the product of other
> emacs-related desktop files. Specificallly, the 'comment' and/or 'generic
> name' should reflect that it will connect to a pre-existing emacs server
> if one exists.
Can you suggest a change along those lines, please?
On 2021-05-16 07:25, Eli Zaretskii wrote:
> > Date: Sat, 15 May 2021 23:33:57 -0400
> > From: Boruch Baum <boruch_baum@gmx.com>
> > Cc: emacs-devel@gnu.org
> >
> > The product should be clearly distinguish-able from the product of other
> > emacs-related desktop files. Specificallly, the 'comment' and/or 'generic
> > name' should reflect that it will connect to a pre-existing emacs server
> > if one exists.
>
> Can you suggest a change along those lines, please?
My suggestion would be: Connect to an Emacs server.
But, I'd prefer that the emacsclient developers decide.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Boruch Baum wrote:
> My suggestion would be: Connect to an Emacs server.
>
> But, I'd prefer that the emacsclient developers decide.
I would like to advance "Open a window in an existing Emacs
editor session" or something along those lines as closer to
the high-level user intent involved, with "and the Emacs
server must be running for this to work" as just a background
precondition. "connect to a server" is easy to interpret as
accessing a third-party network resource, on the surface,
and desktop entry descriptions may be displayed well out
of context as part of lists of other applications. (That
is also why I suggest "window" instead of "frame" above;
the description is desktop-environment-facing, so I would
use that terminology preferentially to Emacs-native terms.)
There's a separate question of whether autolaunch (-a "")
should be enabled. Boruch's initial suggestion included it,
but the current Git version doesn't. On balance, I'd tend
to think of it as less surprising from a desktop perspective
for it to be enabled. In fact, the _least_ surprising from
an XDG/FDO perspective would actually be to _only_ expose
a "client+autolaunch" desktop entry and just call that the
point of integration for Emacs... that would mirror the
behavior of e.g. LibreOffice, Firefox, and many other popular
applications. In that case, you just have something like
"Edit text using Emacs". Or perhaps something longer with
a bit more sparkle to it: imagine a user seeing this entry
and asking "why would I want to edit text using Emacs rather
than something else?"---if there's short-enough phrasing that
can hint at an answer...
-RTT
[-- Attachment #1: Type: text/plain, Size: 674 bytes --] Robin Tarsiger <rtt@dasyatidae.com> writes: > There's a separate question of whether autolaunch (-a "") should be > enabled (...). On balance, I'd tend to think of it as less surprising > from a desktop perspective for it to be enabled. Yes, your proposal makes a lot of sense. As a desktop user (Gnome under Debian or Ubuntu) I found the three icons Emacs, Emacs (Client), Emacs (Terminal) annoying and I often found myself starting the wrong executable or I have to slow my workflow to pay attention to the launcher I am about to start (since all three have the same icon -note that having different icons would help but doesn't go in the right direction from my pov). [-- Attachment #2: Capture d’écran de 2021-05-16 21-55-42.png --] [-- Type: image/png, Size: 746345 bytes --] [-- Attachment #3: Type: text/plain, Size: 14 bytes --] -- Matthias
[-- Attachment #1: Type: text/plain, Size: 305 bytes --] On Sunday 16th May, Robin Tarsiger wrote: > In fact, the _least_ surprising from > an XDG/FDO perspective would actually be to _only_ expose > a "client+autolaunch" desktop entry and just call that the > point of integration for Emacs. Agreed. Attached is a patch which achieves this. -- Peter Oliver [-- Attachment #2: Type: text/plain, Size: 3708 bytes --] From 84508dbc948038f9b7c797b3ec012c00379df7ee Mon Sep 17 00:00:00 2001 From: Peter Oliver <git@mavit.org.uk> Date: Tue, 25 May 2021 22:06:43 +0100 Subject: [PATCH] From a GUI, lauch via emacsclient by default * etc/emacs-mail.desktop, etc/emacs.desktop: Call emacsclient not emacs by default. Provide plain emacs as an alternative action. --- etc/NEWS | 7 +++++++ etc/emacs-mail.desktop | 13 ++++++++++--- etc/emacs.desktop | 11 ++++++++++- etc/emacsclient.desktop | 12 ------------ 4 files changed, 27 insertions(+), 16 deletions(-) delete mode 100644 etc/emacsclient.desktop diff --git a/etc/NEWS b/etc/NEWS index 1541b74a3b..0605c8b46c 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -108,6 +108,13 @@ avoid security issues when executing untrusted code. See the manual page for 'seccomp' system call, for details about Secure Computing filters. +** Launching Emacs from a GUI now defaults to trying emacsclient. +When launching Emacs via a freedesktop.org-compatible GUI, it is now +the default to try to use emacsclient to open the file in an existing +Emacs frame. Opening a new frame in an existing Emacs or a separate +instance of Emacs are available as an alternative action (performed, +for example, by right-clicking on the icon). + \f * Changes in Emacs 28.1 diff --git a/etc/emacs-mail.desktop b/etc/emacs-mail.desktop index 0c5fab1dd1..e949b7f1ed 100644 --- a/etc/emacs-mail.desktop +++ b/etc/emacs-mail.desktop @@ -1,12 +1,19 @@ [Desktop Entry] Categories=Network;Email; Comment=GNU Emacs is an extensible, customizable text editor - and more -Exec=emacs -f message-mailto %u -# If you prefer to use emacsclient, use this instead -#Exec=emacsclient -e '(message-mailto "%u")' +Exec=emacsclient --alternate-editor= --eval '(message-mailto "%u")' Icon=emacs Name=Emacs (Mail) MimeType=x-scheme-handler/mailto; NoDisplay=false Terminal=false Type=Application +Actions=new-window;new-instance; + +[Desktop Action new-window] +Name=New Window +Exec=emacsclient --alternate-editor= --create-frame --eval '(message-mailto "%u")' + +[Desktop Action new-instance] +Name=New Instance +Exec=emacs -f message-mailto %u diff --git a/etc/emacs.desktop b/etc/emacs.desktop index 2e6496e58c..d21bba0e10 100644 --- a/etc/emacs.desktop +++ b/etc/emacs.desktop @@ -3,10 +3,19 @@ Name=Emacs GenericName=Text Editor Comment=Edit text MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++; -Exec=emacs %F +Exec=emacsclient --alternate-editor= %F Icon=emacs Type=Application Terminal=false Categories=Development;TextEditor; StartupWMClass=Emacs Keywords=Text;Editor; +Actions=new-window;new-instance; + +[Desktop Action new-window] +Name=New Window +Exec=emacsclient --alternate-editor= --create-frame %F + +[Desktop Action new-instance] +Name=New Instance +Exec=emacs %F diff --git a/etc/emacsclient.desktop b/etc/emacsclient.desktop deleted file mode 100644 index 3feb83c729..0000000000 --- a/etc/emacsclient.desktop +++ /dev/null @@ -1,12 +0,0 @@ -[Desktop Entry] -Name=Emacs (Client) -GenericName=Text Editor -Comment=Edit text -MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++; -Exec=emacsclient -c %F -Icon=emacs -Type=Application -Terminal=false -Categories=Development;TextEditor; -StartupWMClass=Emacsd -Keywords=Text;Editor; -- 2.31.1
>>>>> On Tue, 25 May 2021 22:34:18 +0100 (BST), Peter Oliver <p.d.oliver@mavit.org.uk> said:
Peter> On Sunday 16th May, Robin Tarsiger wrote:
>> In fact, the _least_ surprising from
>> an XDG/FDO perspective would actually be to _only_ expose
>> a "client+autolaunch" desktop entry and just call that the
>> point of integration for Emacs.
Peter> Agreed. Attached is a patch which achieves this.
I donʼt object to this approach, but I have a couple of points:
- If the user hasn't enabled the server, then this starts emacs in
daemon mode, which needs to be documented somewhere, possibly in
the .desktop file
- Can you document that enabling the server is a pre-requisite
(modulo the daemon behaviour)?
Robert
--
[-- Attachment #1: Type: text/plain, Size: 992 bytes --] On Tue, 25 May 2021, Peter Oliver wrote: > On Sunday 16th May, Robin Tarsiger wrote: > >> In fact, the _least_ surprising from >> an XDG/FDO perspective would actually be to _only_ expose >> a "client+autolaunch" desktop entry and just call that the >> point of integration for Emacs. > > Agreed. Attached is a patch which achieves this. After a bit more testing, I discovered a snag. I believe that the default behaviour when opening a file from a desktop’s file manager should be to open it in an existing GUI frame if one exists, or a new GUI frame if one does not. Clicking Emacs in a desktop’s application launcher should open a new GUI frame. The trouble is that, if Emacs is running as a daemon with no frames, `emacsclient /path/to/foo` will create a new TTY frame rather than a GUI frame. Should this behaviour be changed so that a GUI frame is preferred if $DISPLAY is set? While we’re here, should we report an error if there is no display and no TTY? -- Peter Oliver
> Date: Tue, 25 May 2021 22:34:18 +0100 (BST)
> From: Peter Oliver <p.d.oliver@mavit.org.uk>
>
> > In fact, the _least_ surprising from
> > an XDG/FDO perspective would actually be to _only_ expose
> > a "client+autolaunch" desktop entry and just call that the
> > point of integration for Emacs.
>
> Agreed. Attached is a patch which achieves this.
This is a backward-incompatible change, so why should it be the
default, and not the alternative action via right-click? And anyway,
wouldn't some people be surprised to see emacsclient frame when they
expected a new instance of Emacs, without their say-so?
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --] On Wed, 26 May 2021, Eli Zaretskii wrote: >> Date: Tue, 25 May 2021 22:34:18 +0100 (BST) >> From: Peter Oliver <p.d.oliver@mavit.org.uk> >> >>> In fact, the _least_ surprising from >>> an XDG/FDO perspective would actually be to _only_ expose >>> a "client+autolaunch" desktop entry and just call that the >>> point of integration for Emacs. >> >> Agreed. Attached is a patch which achieves this. > > This is a backward-incompatible change, so why should it be the > default, and not the alternative action via right-click? As argued by others earlier in the thread, this is consistent with the behaviour of other applications that are capable of opening multiple documents in the same window, such as Firefox or Gedit. So, we can say that users who mostly launch things by clicking on icons in their desktops will be likely to expect things to work this way. Conversely, it seems reasonable to worry less about catering for people who do not have this expectation, because we can infer that they rarely click on the icons. > And anyway, > wouldn't some people be surprised to see emacsclient frame when they > expected a new instance of Emacs, without their say-so? My feeling is that plenty of people will find the current behaviour surprising, too. Opening multiple instances of emacs seems like a fairly niche thing to want to do, unless, say, you’re launching it with -Q, in which case you need to run it from the command line anyway. -- Peter Oliver
> Date: Fri, 28 May 2021 13:54:11 +0100 (BST) > From: Peter Oliver <p.d.oliver@mavit.org.uk> > cc: emacs-devel@gnu.org > > > This is a backward-incompatible change, so why should it be the > > default, and not the alternative action via right-click? > > As argued by others earlier in the thread, this is consistent with the behaviour of other applications that are capable of opening multiple documents in the same window, such as Firefox or Gedit. I understand, but it still doesn't sound to me like a reason good enough to make such a serious change in the behavior of Emacs. IMO, it is better to introduce this as an optional behavior for now, and only make it the default much later, if many people come to expect that. > So, we can say that users who mostly launch things by clicking on icons in their desktops will be likely to expect things to work this way. Conversely, it seems reasonable to worry less about catering for people who do not have this expectation, because we can infer that they rarely click on the icons. I don't see how you can make that conclusion with such certainty. Not all the applications behave in that way, so it's quite possible that people don't expect every application to do it. Thus, it isn't a catastrophe that Emacs behaves like it does, and like it did until now. > > And anyway, > > wouldn't some people be surprised to see emacsclient frame when they > > expected a new instance of Emacs, without their say-so? > > My feeling is that plenty of people will find the current behaviour surprising, too. Opening multiple instances of emacs seems like a fairly niche thing to want to do, unless, say, you’re launching it with -Q, in which case you need to run it from the command line anyway. I hear quite a few people run at least two instances of Emacs, for example if they don't want Gnus fetching new articles and email to freeze the interactive session for prolonged times. And there can be other similar reasons to do the same. We don't automatically make new options be the default unless the old behavior makes absolutely no sense or is otherwise dangerous or not useful. I don't see this case matching any of that, so IMO we shouldn't make this behavior the default right away. Does anyone else have an opinion on this aspect?
[-- Attachment #1: Type: text/plain, Size: 2591 bytes --] On Fri, May 28, 2021 at 6:04 AM Eli Zaretskii <eliz@gnu.org> wrote: > > So, we can say that users who mostly launch things by clicking on icons > in their desktops will be likely to expect things to work this way. > Conversely, it seems reasonable to worry less about catering for people who > do not have this expectation, because we can infer that they rarely click > on the icons. > > I don't see how you can make that conclusion with such certainty. Not > all the applications behave in that way, so it's quite possible that > people don't expect every application to do it. Thus, it isn't a > catastrophe that Emacs behaves like it does, and like it did until > now. > My experience with a spread of users who use gui launchers of this sort is that they expect exactly what Peter suggested, and find the current behavior to be obviously broken. I mention this because that feedback is uniform, to the point that people pass around their own home-grown versions of the change suggested here, and they uniformly replace the emacs gui launcher entry, rather than supplement it. Multiple times, I have seen this exchange prompted by a feelign of disbelief that emacs "still can't open new windows instead", followed by the home-grown alternatives. Another common variant is people claiming that Emacs is "incompatible" with gui launchers, with a similar "it can, but you have to fix the defaults" reply. Of course, this is all anecdotal, and it's a little old at this point as I've had very little exposure to a wide user-base in the past year-point-five, but I suggest that this is a good use of the "try it for a while and see" strategy rather than the "ultra-conservative" approach. To be more specific, it seems pretty easy to make the standard behavior the default, and include an option that retains emacs's older behavior, and see which the distros prefer. We could also try asking them directly, if we think we have enough contacts there. Since you asked for opinions.... I suspect the issue is relatively niche. Several years ago, when I was heavily involved in supporting a large user base (MIT students, faculty, and staff), the fact that clicking the launcher-app multiple times got multiple separate emacsen was considered a bug that got reported relatively frequently. The people who wanted multiple isolated emacsen were after very specific outcomes, knew how to get there, and (for the vast majority) weren't using the gui launcher to get there. My instinct is that many people are in that same situation today, but I might be wrong about that. Hope that helps, ~Chad [-- Attachment #2: Type: text/html, Size: 3094 bytes --]
> From: chad <yandros@gmail.com> > Date: Fri, 28 May 2021 11:49:25 -0700 > Cc: Peter Oliver <p.d.oliver@mavit.org.uk>, > EMACS development team <emacs-devel@gnu.org> > > I don't see how you can make that conclusion with such certainty. Not > all the applications behave in that way, so it's quite possible that > people don't expect every application to do it. Thus, it isn't a > catastrophe that Emacs behaves like it does, and like it did until > now. > > My experience with a spread of users who use gui launchers of this sort is that they expect exactly what > Peter suggested, and find the current behavior to be obviously broken. I mention this because that feedback > is uniform, to the point that people pass around their own home-grown versions of the change suggested > here, and they uniformly replace the emacs gui launcher entry, rather than supplement it. Multiple times, I > have seen this exchange prompted by a feelign of disbelief that emacs "still can't open new windows > instead", followed by the home-grown alternatives. Another common variant is people claiming that Emacs is > "incompatible" with gui launchers, with a similar "it can, but you have to fix the defaults" reply. Of course, this > is all anecdotal, and it's a little old at this point as I've had very little exposure to a wide user-base in the past > year-point-five, but I suggest that this is a good use of the "try it for a while and see" strategy rather than the > "ultra-conservative" approach. To be more specific, it seems pretty easy to make the standard behavior the > default, and include an option that retains emacs's older behavior, and see which the distros prefer. We > could also try asking them directly, if we think we have enough contacts there. I suggest to do this the other way around: make this new behavior optional, until we are sure people expect that. Don't forget that client-based sessions behave differently from "normal" sessions: "C-x C-c" doesn't exit Emacs, activating a minibuffer in one frame will prevent input on other frames, etc. This is peculiar to Emacs; other applications don't have these potentially confusing aspects, they just open a new app window (and then users close them by the mouse, unlike typical Emacs usage). IOW, client-driven sessions are not exactly what people are used to with other applications that open a new window instead a new instance. As usual, we are trying to pretend that some feature peculiar to Emacs that doesn't really have an equivalent in other applications is and should be used like some similar feature in other programs. We tweak Emacs behavior and use patterns to support the pretense, but doing so doesn't make the differences go away. We shouldn't bend our thinking like that, just because we see some trend in other applications and think we can easily follow it with something similar. > Since you asked for opinions.... I suspect the issue is relatively niche. Several years ago, when I was heavily > involved in supporting a large user base (MIT students, faculty, and staff), the fact that clicking the > launcher-app multiple times got multiple separate emacsen was considered a bug that got reported relatively > frequently. The people who wanted multiple isolated emacsen were after very specific outcomes, knew how > to get there, and (for the vast majority) weren't using the gui launcher to get there. My instinct is that many > people are in that same situation today, but I might be wrong about that. Then please explain to me why the time it takes Emacs to start is still such a hot topic, on Redit, help-gnu-emacs and elsewhere. That clearly indicates that people do start Emacs many times, instead of having a single long-running session.
[-- Attachment #1: Type: text/plain, Size: 3233 bytes --] On Fri, May 28, 2021 at 12:16 PM Eli Zaretskii <eliz@gnu.org> wrote: > I suggest to do this the other way around: make this new behavior > optional, until we are sure people expect that. > [...] We shouldn't bend our thinking > like that, just because we see some trend in other applications and > think we can easily follow it with something similar. > Sure, the conservative approach works here also. What I was suggesting was basically "let's give the distros both options and ask/see which they pick". Since we're generally sensitive to changing defaults on releases, I think there are ways to ask before releasing, but the data collection is likely to be sparse. > > > Since you asked for opinions.... I suspect the issue is relatively > niche. Several years ago, when I was heavily > > involved in supporting a large user base (MIT students, faculty, and > staff), the fact that clicking the > > launcher-app multiple times got multiple separate emacsen was considered > a bug that got reported relatively > > frequently. The people who wanted multiple isolated emacsen were after > very specific outcomes, knew how > > to get there, and (for the vast majority) weren't using the gui launcher > to get there. My instinct is that many > > people are in that same situation today, but I might be wrong about that. > > Then please explain to me why the time it takes Emacs to start is > still such a hot topic, on Redit, help-gnu-emacs and elsewhere. That > clearly indicates that people do start Emacs many times, instead of > having a single long-running session. > Speaking to my past experience: people would end up with multiple emacsen running, and if they ever noticed that fact, it was the opposite of what they wanted. Lack of shared state like confusing history and accidentally using old code because of unsaved changes in a separate emacs were common complaints, performance concerns were even more common. To the "startup time discussion" point, though, I think the current discussions are a mixture of debating with history (ala "we use vi because emacs is giant and slow"), people switching contexts frequently (rather than reusing the same session on the same machines most of the time, also exemplified in the people who use TTY emacs in gui sessions rather than display-juggling and/or tramp; especially common among people using containers, VMs, etc), and people who fall into the trap created by the default use pattern starting new emacsen rather than reusing an existing one. A small percentage of them end up restarting emacs frequently because they frequently rebuild it -- something that I know is too painful for you, Stefan, and Richard to do often, but that I see happening several times a week. Put another way, I think you've identified a symptom of the problem that the change is intended to fix. Many (most?) of the people I talk to in that situation are pleasantly surprised to learn that there is a not-so-complicated way to fix it. For example, I have personally talked to multiple people with complicated AppleScript setups designed to fix this problem, and generally made them happy and occasionally chagrined when I tell them that what they now want is 'emacsclient -c -a ""'. ~Chad [-- Attachment #2: Type: text/html, Size: 3918 bytes --]
> From: chad <yandros@gmail.com>
> Date: Fri, 28 May 2021 13:05:30 -0700
> Cc: Peter Oliver <p.d.oliver@mavit.org.uk>,
> EMACS development team <emacs-devel@gnu.org>
>
> On Fri, May 28, 2021 at 12:16 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> I suggest to do this the other way around: make this new behavior
> optional, until we are sure people expect that.
> [...] We shouldn't bend our thinking
> like that, just because we see some trend in other applications and
> think we can easily follow it with something similar.
>
> Sure, the conservative approach works here also. What I was suggesting was basically "let's give the distros
> both options and ask/see which they pick". Since we're generally sensitive to changing defaults on releases,
> I think there are ways to ask before releasing, but the data collection is likely to be sparse.
Distros can do whatever they like anyway, and we have no real control
of that.
> I hear quite a few people run at least two instances of Emacs, for > example if they don't want Gnus fetching new articles and email to > freeze the interactive session for prolonged times. And there can > be other similar reasons to do the same. > > We don't automatically make new options be the default unless the > old behavior makes absolutely no sense or is otherwise dangerous or > not useful. I don't see this case matching any of that, so IMO we > shouldn't make this behavior the default right away. > > Does anyone else have an opinion on this aspect? Sorry if I did not follow this thread before and ended up opening bug #49505. As stated there, if possible I'd like to keep the old behaviour on left-click (new Emacs instance) and offering an 'Emacs (client)' option on right-click. The change was a bit of surprise for me, and it took some adjustments on my side: - I have two launchers now in GNOME Activities overview when I type 'emacs': 'Emacs' and 'Emacs (Client)' - Whichever I add to my favourites, the dock bar shows 'Emacs (Client)' - It's only by right-clicking on that 'Emacs (Client)' and picking 'New Instance' that I get the Emacs instance I was used to. Another way is not using the launcher in the dock, but left-clicking on the 'Emacs' launcher in GNOME Activities overview. - For now my workaround has been using a keyboard shortcut ('s-e') to open 'emacs', but yes, this was kind of an undesired change. -- Manuel Uberti www.manueluberti.eu
> From: Manuel Uberti <manuel.uberti@inventati.org>
> Date: Thu, 12 Aug 2021 14:42:29 +0200
>
> > I hear quite a few people run at least two instances of Emacs, for
> > example if they don't want Gnus fetching new articles and email to
> > freeze the interactive session for prolonged times. And there can > be other
> similar reasons to do the same.
> >
> > We don't automatically make new options be the default unless the
> > old behavior makes absolutely no sense or is otherwise dangerous or > not
> useful. I don't see this case matching any of that, so IMO we
> > shouldn't make this behavior the default right away.
> >
> > Does anyone else have an opinion on this aspect?
>
> Sorry if I did not follow this thread before and ended up opening bug #49505. As
> stated there, if possible I'd like to keep the old behaviour on left-click (new
> Emacs instance) and offering an 'Emacs (client)' option on right-click.
Needless to say, I agree with you, but other opinions prevailed.
Hopefully, it isn't too late to correct that in some way.
Eli Zaretskii <eliz@gnu.org> writes: >> Sorry if I did not follow this thread before and ended up opening >> bug #49505. As >> stated there, if possible I'd like to keep the old behaviour on >> left-click (new >> Emacs instance) and offering an 'Emacs (client)' option on right-click. > > Needless to say, I agree with you, but other opinions prevailed. > Hopefully, it isn't too late to correct that in some way. Yes, we should go back to the old behaviour here, I think. But the discussion is happening in bug#49505; there's no need to have half of the discussion on emacs-devel. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no