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

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

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

Could it be related to bug #49505?

-- 
Manuel Uberti
www.manueluberti.eu

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

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

This was created by mistake and can be closed.

Sorry about that, I have already replied to the correct bug report.

-- 
Manuel Uberti
www.manueluberti.eu

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

[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

[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

[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

[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

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