bug#49505: 28.0.50; Multiple launchers in GNOME

bug#49505: 28.0.50; Multiple launchers in GNOME

[Manuel Uberti]

[-- Attachment #1: Type: text/plain, Size: 5014 bytes --]

Hi,

I built Emacs master (commit: 3fa711c11d1497418fdf8a866b7ba52dd3b00e0e)
and now I see two launchers (.desktop files) in GNOME:

- Emacs
- Emacs (Client)

The first one is the one I added to my favourites in GNOME, thus it's the 
launcher I've always used in my GNOME dash panel to launch Emacs. See attachment 
1.png.

However, this launcher now always spawns a new Emacs (Client), resulting in two 
Emacs icons in my GNOME dash. See attachment 2.png.


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.18, cairo 
version 1.16.0) of 2021-07-10 built on hathaway
Repository revision: 3fa711c11d1497418fdf8a866b7ba52dd3b00e0e
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Ubuntu 20.04 LTS

Configured using:
  'configure --with-harfbuzz --with-native-compilation CC=gcc-10'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
   value of $LC_MONETARY: it_IT.UTF-8
   value of $LC_NUMERIC: it_IT.UTF-8
   value of $LC_TIME: it_IT.UTF-8
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
   icomplete-vertical-mode: t
   icomplete-mode: t
   save-place-mode: t
   global-company-mode: t
   company-mode: t
   git-identity-magit-mode: t
   minibuffer-depth-indicate-mode: t
   minibuffer-electric-default-mode: t
   recentf-mode: t
   savehist-mode: t
   global-diff-hl-mode: t
   mu-keys-mode: t
   global-eldoc-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   window-divider-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Load-path shadows:
/home/manuel/.emacs.d/elpa/transient-20210701.1116/transient hides 
/usr/local/share/emacs/28.0.50/lisp/transient

Features:
(shadow sort flymake-proc flymake compile comint ansi-color vc-git
goto-addr thingatpt mail-extr emacsbug message rmc puny rfc822 mml
mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail comp comp-cstr warnings
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cursor-sensor
icomplete saveplace company-oddmuse company-keywords company-etags etags
fileloop generator xref project company-gtags company-dabbrev-code
company-dabbrev company-files company-clang company-capf company-cmake
company-semantic company-template company-bbdb company git-identity f
dash s modus-operandi-theme modus-themes autorevert filenotify dired-x
dired-aux dired dired-loaddefs mb-depth minibuf-eldef mode-local advice
find-func recentf tree-widget wid-edit savehist diff-hl log-view
pcvs-util vc-dir ewoc vc vc-dispatcher diff-mode modeline packages
pdf-loader cl-extra help-mode hydra ring lv built-ins rx pcase ibuf-macs
derived core-settings edmacro kmacro disp-table core-packages
no-littering core-lib easy-mmode tex-site info package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 265148 29271)
  (symbols 48 18464 1)
  (strings 32 53598 3783)
  (string-bytes 1 1798929)
  (vectors 16 29296)
  (vector-slots 8 531093 10580)
  (floats 8 163 978)
  (intervals 56 598 0)
  (buffers 992 11))

-- 
Manuel Uberti
www.manueluberti.eu

[-- Attachment #2: 1.png --]
[-- Type: image/png, Size: 90105 bytes --]

[-- Attachment #3: 2.png --]
[-- Type: image/png, Size: 65632 bytes --]

bug#49505: 28.0.50; Multiple launchers in GNOME

[Manuel Uberti]

FTR, running emacs -Q from the command line spawns a new Emacs (Client) launcher 
in my dash panel as well.

-- 
Manuel Uberti
www.manueluberti.eu

bug#49505: 28.0.50; Multiple launchers in GNOME

[Lars Ingebrigtsen]

Manuel Uberti <manuel.uberti@inventati.org> writes:

> I built Emacs master (commit: 3fa711c11d1497418fdf8a866b7ba52dd3b00e0e)
> and now I see two launchers (.desktop files) in GNOME:
>
> - Emacs
> - Emacs (Client)
>
> The first one is the one I added to my favourites in GNOME, thus it's
> the launcher I've always used in my GNOME dash panel to launch
> Emacs. See attachment 1.png.
>
> However, this launcher now always spawns a new Emacs (Client),
> resulting in two Emacs icons in my GNOME dash. See attachment 2.png.

I think this might be due to the recent changed here by Peter (added to
the CCs).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49505: 28.0.50; Multiple launchers in GNOME

[Manuel Uberti]

For now, I see that by doing the following I only get one launcher in the Dash 
panel:

- Add Emacs (Client) to favourites
- Right-click on it
- Select New Instance

I don't know if this is what Peter had in mind for the user to do, though.

-- 
Manuel Uberti
www.manueluberti.eu

bug#49505: 28.0.50; Multiple launchers in GNOME

[Manuel Uberti]

While we wait for Peter to get back on this, would it be possible to revert his 
changes?

-- 
Manuel Uberti
www.manueluberti.eu

bug#49505: 28.0.50; Multiple launchers in GNOME

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]

On Sat, 10 Jul 2021, Lars Ingebrigtsen wrote:

> Manuel Uberti <manuel.uberti@inventati.org> writes:
>
>> I built Emacs master (commit: 3fa711c11d1497418fdf8a866b7ba52dd3b00e0e)
>> and now I see two launchers (.desktop files) in GNOME:
>>
>> - Emacs
>> - Emacs (Client)
>>
>> The first one is the one I added to my favourites in GNOME, thus it's
>> the launcher I've always used in my GNOME dash panel to launch
>> Emacs. See attachment 1.png.
>>
>> However, this launcher now always spawns a new Emacs (Client),
>> resulting in two Emacs icons in my GNOME dash. See attachment 2.png.
>
> I think this might be due to the recent changed here by Peter (added to
> the CCs).

Yes, I think this will be caused by the fix to bug 49259.

> For now, I see that by doing the following I only get one launcher in the Dash 
> panel:
> 
> - Add Emacs (Client) to favourites
> - Right-click on it
> - Select New Instance
> 
> I don't know if this is what Peter had in mind for the user to do, though.

Pretty much, yes.  You should be able to use emacsclient.desktop for everything.  By the way, if you’re launching Emacs for the first time in a session, you shouldn’t need to right-click and select New Instance.  Left clicking should cause a new instance to run if there is no existing instance.

The duplicate icons are annoying, though.

It’s my view that we should provide only one .desktop file (namely emacsclient.desktop, renamed to emacs.desktop).  However, when this was discussed at <https://lists.gnu.org/archive/html/emacs-devel/2021-05/msg00648.html>, consensus was not reached.

It’s my suspicion that implementing the Freedesktop.org startup notification protocol in emacsclient, as proposed in bug 49504, would also cause this issue to go away, because the desktop would be able to identify which window was opened as a result of clicking on which icon.  However, that seems controversial, too.

I’m not sure what else to suggest.  We can revert the fix to 49259 (or, more sensibly, remove StartupWMClass from emacsclient.desktop entirely), but that doesn’t really help, since it’d cause the opposite problem that people who favourite “Emacs (Client)” would end up with a duplicate “Emacs” icon.

-- 
Peter Oliver

bug#49505: 28.0.50; Multiple launchers in GNOME

[Manuel Uberti]

On 10/08/21 23:22, Peter Oliver wrote:
> Pretty much, yes.  You should be able to use emacsclient.desktop for 
> everything.  By the way, if you’re launching Emacs for the first time in a 
> session, you shouldn’t need to right-click and select New Instance.  Left 
> clicking should cause a new instance to run if there is no existing instance.

It isnt' so, though. If I left-click on the Emacs (client) I always get an Emacs 
client, the first time too.

-- 
Manuel Uberti
www.manueluberti.eu

bug#49505: 28.0.50; Multiple launchers in GNOME

[Utkarsh Singh]

Hello Manuel,

On 2021-07-25, 08:38 +0200, Manuel Uberti <manuel.uberti@inventati.org> wrote:

> While we wait for Peter to get back on this, would it be possible to revert his 
> changes?

I also noticed the same bug but considered it to be a feature (though it
should be fixed).

To solve the problem of two icons I replaced my Emacs with Emacs
(Client) launcher in the favourites panel.  Now in bonus, I always have
a Emacs process running in the background, waiting to be connected.

-- 
Utkarsh Singh
http://utkarshsingh.xyz

bug#49505: 28.0.50; Multiple launchers in GNOME

[Lars Ingebrigtsen]

Peter Oliver <p.d.oliver@mavit.org.uk> writes:

> It’s my view that we should provide only one .desktop file (namely
> emacsclient.desktop, renamed to emacs.desktop).  However, when this
> was discussed at
> <https://lists.gnu.org/archive/html/emacs-devel/2021-05/msg00648.html>,
> consensus was not reached.

Some people use emacsclient, and others never do so.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49505: 28.0.50; Multiple launchers in GNOME

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Wed, 11 Aug 2021, Manuel Uberti wrote:

> On 10/08/21 23:22, Peter Oliver wrote:
>>  Pretty much, yes.  You should be able to use emacsclient.desktop for
>>  everything.  By the way, if you’re launching Emacs for the first time in a
>>  session, you shouldn’t need to right-click and select New Instance.  Left
>>  clicking should cause a new instance to run if there is no existing
>>  instance.
>
> It isnt' so, though. If I left-click on the Emacs (client) I always get an 
> Emacs client, the first time too.

But in this case, emacsclient automatically starts emacs for you, doesn’t it?

-- 
Peter Oliver

bug#49505: 28.0.50; Multiple launchers in GNOME

[Manuel Uberti]

On 11/08/21 19:34, Peter Oliver wrote:
> But in this case, emacsclient automatically starts emacs for you, doesn’t it?

It starts emacs, but it offers me a client.

However, all I want is just one Emacs standalone (i.e. non-client) instance. I 
understand others make use of emacsclient much more than I do, and if this helps 
them it is something good of course.

In my case, though, it's something I've never used before and I don't see why 
now I cannot opt out of it.

-- 
Manuel Uberti
www.manueluberti.eu

bug#49505: 28.0.50; Multiple launchers in GNOME

[Manuel Uberti]

Are there any plans to fix or at least revert this behaviour?

IIUC, the desired behavior is to have a new instance only on the first 
left-click on the emacsclient.desktop icon, although I'd prefer if left-clicking 
always brought up a new instance.

-- 
Manuel Uberti
www.manueluberti.eu

bug#49505: 28.0.50; Multiple launchers in GNOME

[Lars Ingebrigtsen]

Manuel Uberti <manuel.uberti@inventati.org> writes:

> Are there any plans to fix or at least revert this behaviour?
>
> IIUC, the desired behavior is to have a new instance only on the first
> left-click on the emacsclient.desktop icon, although I'd prefer if
> left-clicking always brought up a new instance.

Yes, left-clicking should only bring up a new instance on the first
left-click -- that's how all the other launchers work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49505: 28.0.50; Multiple launchers in GNOME

[Simen Heggestøyl]

Manuel Uberti <manuel.uberti@inventati.org> writes:

> Are there any plans to fix or at least revert this behaviour?

This bug has been biting me too since switching to the emacs-28 branch.

I agree with Manuel that it should be reverted until a fix is ready.

bug#49505: 28.0.50; Multiple launchers in GNOME

[Lars Ingebrigtsen]

Simen Heggestøyl <simenheg@runbox.com> writes:

>> Are there any plans to fix or at least revert this behaviour?
>
> This bug has been biting me too since switching to the emacs-28 branch.
>
> I agree with Manuel that it should be reverted until a fix is ready.

Yup.  There's been several patches here, though, so I'm not quite sure
what to revert.  Can you propose a patch that fixes this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49505: 28.0.50; Multiple launchers in GNOME

[Simen Heggestøyl]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Simen Heggestøyl <simenheg@runbox.com> writes:
>
>>> Are there any plans to fix or at least revert this behaviour?
>>
>> This bug has been biting me too since switching to the emacs-28 branch.
>>
>> I agree with Manuel that it should be reverted until a fix is ready.
>
> Yup.  There's been several patches here, though, so I'm not quite sure
> what to revert.  Can you propose a patch that fixes this?

Peter's suggestion to remove the StartupWMClass line from
emacsclient.desktop fixes the "Emacs" launcher:

> I’m not sure what else to suggest.  We can revert the fix to 49259
> (or, more sensibly, remove StartupWMClass from emacsclient.desktop
> entirely), but that doesn’t really help, since it’d cause the opposite
> problem that people who favourite “Emacs (Client)” would end up with a
> duplicate “Emacs” icon.

But as he says, it flips the bug around to hit users of the new "Emacs
(Client)" launcher instead...

Deleting emacsclient.desktop would bring back the behavior of Emacs 27 I
suppose, but I don't know whether having a slightly buggy "Emacs
(Client)" launcher is better than having no "Emacs (Client)" launcher at
all.

bug#49505: 28.0.50; Multiple launchers in GNOME

[Lars Ingebrigtsen]

Simen Heggestøyl <simenheg@runbox.com> writes:

> Deleting emacsclient.desktop would bring back the behavior of Emacs 27 I
> suppose, but I don't know whether having a slightly buggy "Emacs
> (Client)" launcher is better than having no "Emacs (Client)" launcher at
> all.

A slightly buggy "Emacs (Client)" launcher sounds slightly less worse
than the current situation.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49505: 28.0.50; Multiple launchers in GNOME

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On Wed, 11 Aug 2021, Manuel Uberti wrote:

> On 11/08/21 19:34, Peter Oliver wrote:
>>  But in this case, emacsclient automatically starts emacs for you, doesn’t
>>  it?
>
> It starts emacs, but it offers me a client.
>
> However, all I want is just one Emacs standalone (i.e. non-client) instance. 
> I understand others make use of emacsclient much more than I do, and if this 
> helps them it is something good of course.
>
> In my case, though, it's something I've never used before and I don't see why 
> now I cannot opt out of it.

Does starting a server cause a problem?  Could people largely ignore that it’s happening and carry on as normal?  Genuine question.  I always start a server, so I don’t have experience of how Emacs behaves differently without one.

I realise that closing an Emacs client window via the window manager will cause an Emacs daemon to carry on running in the background until the end of the desktop session, which would be different behaviour to most other desktop apps, but perhaps it’s tolerable nonetheless.  Modern desktops run so many processes in the background, after all, that one more might not make much difference.

-- 
Peter Oliver

bug#49505: 28.0.50; Multiple launchers in GNOME

[Lars Ingebrigtsen]

Peter Oliver <p.d.oliver@mavit.org.uk> writes:

> Does starting a server cause a problem?  Could people largely ignore
> that it’s happening and carry on as normal?  Genuine question.  I
> always start a server, so I don’t have experience of how Emacs behaves
> differently without one.

Most people do not ever use a server, and starting a server would be
confusing for those people.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49505: 28.0.50; Multiple launchers in GNOME

[Manuel Uberti]

On 09/10/21 13:29, Lars Ingebrigtsen wrote:
> Peter Oliver <p.d.oliver@mavit.org.uk> writes:
> 
>> Does starting a server cause a problem?  Could people largely ignore
>> that it’s happening and carry on as normal?  Genuine question.  I
>> always start a server, so I don’t have experience of how Emacs behaves
>> differently without one.
> 
> Most people do not ever use a server, and starting a server would be
> confusing for those people.
> 

Basically what Lars said. I do not start a server and I do not have any use for it.

-- 
Manuel Uberti
www.manueluberti.eu

bug#49505: 28.0.50; Multiple launchers in GNOME

[Tim Ruffing]

Hi,

this is not yet solved. I tried to investigate it and it's quite a
rabbit hole:

So GNOME (and I suppose the same for KDE?) can't track "windows"
started by emacsclient properly, which is the problem as initially
reported by Manuel here. This problem still exists and I encounter it,
too: 

We currently offer two .desktop files both specifying *the same*
StartupWMClass=Emacs. This means that desktop environments can't match
windows to applications. When my GNOME sees a windows with WMClass
"Emacs", it assigns it arbitrarily to emacs.desktop ("Emacs") and not
emacsclient.desktop ("Emacs (Client)") because there's no unique match.
That means that when I click the "Emacs (Client)" icon in my dash, a
window is created but GNOME assumes it belongs to "Emacs", creating
another icon in my dash representing the "Emacs" window. This is wrong
and very inconvenient.

There are two ways that can be fixed, either we should have only a
single application (i.e., .desktop file) or we should make sure that
windows from emacs and emacsclient can be distinguished based on their
wmclass:

----

1. Unify the .desktop files

I know this has been tried already and was reverted because that
particular approach has forced users into using the daemon, which I
fully agree was not a good idea. What we could do instead is to have
have a single emacs.desktop that simply does the following:

Try to connect to daemon and create a new frame, if there's no daemon,
just launch a new instance (e.g., using emacsclient -a emacs).

This will get an automatic "New Window" action in the context menu (at
least in GNOME, need to check for others), because if you left-click
again, you'll simply switch to an existing window.

That's very simple, and it always will manage to bring up emacs, so
it's "safe" for the average user. It won't confuse new users because
who don't know whether they should launch "Emacs" or "Emacs (Client)".

And it leaves decision of using the daemon to the user, who can enable
or disable it using systemctl (or other ways) on normal desktops. If
didn't opt in to run a daemon, you won't even notice that emacs has a
daemon mode.

Advanced users who need something special, e.g, they want to bring up a
new non-daemon instance even though a daemon is running, can still
customize and create their own .desktop files or shortcuts. This is
nothing we should optimize for.

The only drawback of this approach is that ideally "New Window" would
bring up a just a new frame but this will work only in daemon mode. In
non-daemon mode, you'll get a new instance.

But I'm not sure if this could be solved quickly because I'm not sure
if there's a way to ask a non-daemon emacs to create a new frame. I
think in the long-term we could for example use D-Bus activation [1]
and make non-daemon emacs expose a dbus service that can create frames.
But that's a larger project. Ideally there would be a "semi-daemon"
mode, which is in between the daemon mode and the normal mode: The
first invocation launches a daemon, further invocations (e.g., using
emacsclient, or dbus) would just create new frames BUT if you close the
last frame, no daemon will stay around. This would exactly match the
behavior of other desktop applications.

----

2. Keep the .desktop files separate, and use separate wmclasses for
daemon and non-daemon mode

This has also been attempted in
1a845a672dc73c8e98e6cb9bb734616e168e60ba by changing argv[0] but this
was reverted by f355f32e69b1389f7d51b8a50c0a9c064dc2cb32 because
changing argv[0] is not a great idea. But we could change wmclass
differently, just by calling gtk_init() with a different string
depending on whether we're in daemon mode or not.

I think that would also work. This comes with a risk of breaking some
user scripts / config that rely on the wmclass instance name (similar
to how some things relied on matching argv[0]) but I don't think
that'll be a big deal.

----

In the end, I'd favor the first approach. A single .desktop will offer
the same functionality as we have currently, will confuse users less
than the currently separate files, and is on the right track for an
better solution in the long-term.

Moreover, the first approach can probably simplify the mess a little
bit because we should be able to drop "StartupWMClass" entirely, which
would probably avoid some more problems [4]. 

What do you think? I'd be willing to create a patch for either of the
approaches but I first wanted to check here because this seems a
complex and controversial topic.

Tim

PS: An entirely different issue is "startup notification" with the
emacsclient, i.e., the desktop environment has noticed that the app has
started up and can turn off the "waiting spinner" for example. This
needs some passing around of startup ids, which we currently don't do
via emacsclient. But that's far less annoying in practice. I can create
a separate bug for that.

[1] https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus
[2] Currently on GNOME on Wayland, the match based on StartupWMClass
doesn't work due to the different capitalization in the Wayland appid
(somewhat equivalent to WM_CLASS on X), which is "emacs". Setting
StartupWMClass is not necessary AFAIU, and desktop environments will
simply match based on the filename of the .desktop file and case
doesn't seem to matter here. The actual logic is pretty ugly (GNOME
[3], KDE [4]) and we so we should test this. One of the problems here
is that WM_CLASS consists of two strings in fact, the "name" and the
"class". In our case that's "emacs" and "Emacs", and the freedesktop
spec for .desktop doesn't specify which one should be taken...
[3] https://github.com/GNOME/gnome-shell/blob/main/src/shell-window-tracker.c#L198
[4] https://github.com/KDE/plasma-workspace/blob/070009a5cb9387596230c6008102a288f7972ba5/libtaskmanager/tasktools.cpp#L195

bug#49505: 28.0.50; Multiple launchers in GNOME

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tim Ruffing <public@timruffing.de> writes:

> We currently offer two .desktop files both specifying *the same*
> StartupWMClass=Emacs. This means that desktop environments can't match
> windows to applications. When my GNOME sees a windows with WMClass
> "Emacs", it assigns it arbitrarily to emacs.desktop ("Emacs") and not
> emacsclient.desktop ("Emacs (Client)") because there's no unique match.
> That means that when I click the "Emacs (Client)" icon in my dash, a
> window is created but GNOME assumes it belongs to "Emacs", creating
> another icon in my dash representing the "Emacs" window. This is wrong
> and very inconvenient.
>
> There are two ways that can be fixed, either we should have only a
> single application (i.e., .desktop file) or we should make sure that
> windows from emacs and emacsclient can be distinguished based on their
> wmclass:

I would prefer to only have a single desktop file.

> 2. Keep the .desktop files separate, and use separate wmclasses for
> daemon and non-daemon mode
>
> This has also been attempted in
> 1a845a672dc73c8e98e6cb9bb734616e168e60ba by changing argv[0] but this
> was reverted by f355f32e69b1389f7d51b8a50c0a9c064dc2cb32 because
> changing argv[0] is not a great idea. But we could change wmclass
> differently, just by calling gtk_init() with a different string
> depending on whether we're in daemon mode or not.

Not a good idea.  Besides, the Emacs server can also be started inside a
running session, so that wouldn't work perfectly either.

We can have fine-grained control over WM_CLASS (despite whatever the
toolkit does), since Emacs can use X Windows requests to directly set
the WM_CLASS property, but changing that for individual frames based on
how they were created sounds excessive to me.

bug#49505: 28.0.50; Multiple launchers in GNOME

[Tim Ruffing]

Thanks for the comments.

On Tue, 2022-05-24 at 21:39 +0800, Po Lu wrote:
> We can have fine-grained control over WM_CLASS (despite whatever the
> toolkit does), since Emacs can use X Windows requests to directly set
> the WM_CLASS property, but changing that for individual frames based
> on
> how they were created sounds excessive to me.

Note that we wouldn't need to do it for individual frames. If emacs was
started in non-daemon mode, we would use some string X for all its
frames, and if emacs was started in daemon mode, we would use some
string Y for all its frames. 

But as I said, I also prefer the approach that has only a single
.desktop file, so we wouldn't need to bother with this at all.

Best,
Tim
  

bug#49505: 28.0.50; Multiple launchers in GNOME

[Lars Ingebrigtsen]

Tim Ruffing <public@timruffing.de> writes:

> 1. Unify the .desktop files
>
> I know this has been tried already and was reverted because that
> particular approach has forced users into using the daemon, which I
> fully agree was not a good idea. What we could do instead is to have
> have a single emacs.desktop that simply does the following:
>
> Try to connect to daemon and create a new frame, if there's no daemon,
> just launch a new instance (e.g., using emacsclient -a emacs).

[...]

> The only drawback of this approach is that ideally "New Window" would
> bring up a just a new frame but this will work only in daemon mode. In
> non-daemon mode, you'll get a new instance.

I think this sounds like a sound approach.  Can you prepare a patch for
this so we can try it out?

> But I'm not sure if this could be solved quickly because I'm not sure
> if there's a way to ask a non-daemon emacs to create a new frame. I
> think in the long-term we could for example use D-Bus activation [1]
> and make non-daemon emacs expose a dbus service that can create frames.
> But that's a larger project. Ideally there would be a "semi-daemon"
> mode, which is in between the daemon mode and the normal mode: The
> first invocation launches a daemon, further invocations (e.g., using
> emacsclient, or dbus) would just create new frames BUT if you close the
> last frame, no daemon will stay around. This would exactly match the
> behavior of other desktop applications.

Yes, that'd be nice.  Using dbus for this (perhaps via emacsclient?)
might be the right approach here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49505: 28.0.50; Multiple launchers in GNOME

[Peter Oliver]

On Tue, 24 May 2022, Tim Ruffing wrote:

> Ideally there would be a "semi-daemon"
> mode, which is in between the daemon mode and the normal mode: The
> first invocation launches a daemon, further invocations (e.g., using
> emacsclient, or dbus) would just create new frames BUT if you close the
> last frame, no daemon will stay around. This would exactly match the
> behavior of other desktop applications.

We have this behaviour in Emacs 29.  To get it, a user has to opt-in by calling function server-stop-automatically.

-- 
Peter Oliver

bug#49505: bug#51749: 29.0.50; Emacs 29 Creates Only Emacsclient Icon in Ubuntu Dock

[Lars Ingebrigtsen]

Peter Oliver <p.d.oliver@mavit.org.uk> writes:

>> Ideally there would be a "semi-daemon"
>> mode, which is in between the daemon mode and the normal mode: The
>> first invocation launches a daemon, further invocations (e.g., using
>> emacsclient, or dbus) would just create new frames BUT if you close the
>> last frame, no daemon will stay around. This would exactly match the
>> behavior of other desktop applications.
>
> We have this behaviour in Emacs 29.  To get it, a user has to opt-in
> by calling function server-stop-automatically.

I've only lightly skimmed this bug report -- does this mean that this
bug report can be closed?

bug#51749: 29.0.50; Emacs 29 Creates Only Emacsclient Icon in Ubuntu Dock

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Peter Oliver <p.d.oliver@mavit.org.uk> writes:
>
>>> Ideally there would be a "semi-daemon"
>>> mode, which is in between the daemon mode and the normal mode: The
>>> first invocation launches a daemon, further invocations (e.g., using
>>> emacsclient, or dbus) would just create new frames BUT if you close the
>>> last frame, no daemon will stay around. This would exactly match the
>>> behavior of other desktop applications.
>>
>> We have this behaviour in Emacs 29.  To get it, a user has to opt-in
>> by calling function server-stop-automatically.
>
> I've only lightly skimmed this bug report -- does this mean that this
> bug report can be closed?

More information was requested, but none was given within ~10 months, so
I'm closing this bug.  If this is still an issue, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.