Re: GUI X-FreeDesktop integration

Re: GUI X-FreeDesktop integration

[Peter Oliver]

[-- 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

Re: GUI X-FreeDesktop integration

[Robert Pluim]

>>>>> 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
-- 

Re: GUI X-FreeDesktop integration

[Peter Oliver]

[-- 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

Re: GUI X-FreeDesktop integration

[Eli Zaretskii]

> 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?

Re: GUI X-FreeDesktop integration

[Peter Oliver]

[-- 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

Re: GUI X-FreeDesktop integration

[Eli Zaretskii]

> 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?

Re: GUI X-FreeDesktop integration

[chad]

[-- 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 --]

Re: GUI X-FreeDesktop integration

[Eli Zaretskii]

> 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.

Re: GUI X-FreeDesktop integration

[chad]

[-- 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 --]

Re: GUI X-FreeDesktop integration

[Eli Zaretskii]

> 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.

Re: GUI X-FreeDesktop integration

[Manuel Uberti]

 > 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

Re: GUI X-FreeDesktop integration

[Eli Zaretskii]

> 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.

Re: GUI X-FreeDesktop integration

[Lars Ingebrigtsen]

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

GUI X-FreeDesktop integration

[Boruch Baum]

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

Re: GUI X-FreeDesktop integration

[Stefan Monnier]

> 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

Re: GUI X-FreeDesktop integration

[Boruch Baum]

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

Re: GUI X-FreeDesktop integration

[Eli Zaretskii]

> 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.

Re: GUI X-FreeDesktop integration

[Joost Kremers]

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

Re: GUI X-FreeDesktop integration

[Eli Zaretskii]

> 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.)

Re: GUI X-FreeDesktop integration

[Joost Kremers]

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

Re: GUI X-FreeDesktop integration

[Yuri Khan]

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

Re: GUI X-FreeDesktop integration

[Stefan Monnier]

> 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

Re: GUI X-FreeDesktop integration

[Boruch Baum]

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

Re: GUI X-FreeDesktop integration

[Eli Zaretskii]

> 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?

Re: GUI X-FreeDesktop integration

[Boruch Baum]

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

Re: GUI X-FreeDesktop integration

[Robin Tarsiger]

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

Re: GUI X-FreeDesktop integration

[Matthias Meulien]

[-- 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