GNU bug report logs - #58404
29.0.50; [PATCH] When killing Emacs from the last client, don't warn about the session having clients

Previous Next

Package: emacs;

Reported by: Jim Porter <jporterbugs <at> gmail.com>

Date: Sun, 9 Oct 2022 23:33:01 UTC

Severity: normal

Tags: patch

Found in version 29.0.50

Done: Jim Porter <jporterbugs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 58404 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58404 <at> debbugs.gnu.org
Subject: Re: bug#58404: 29.0.50; [PATCH] When killing Emacs from the last
 client, don't warn about the session having clients
Date: Mon, 10 Oct 2022 01:08:17 -0700
On 10/9/2022 11:11 PM, Eli Zaretskii wrote:
> IMO, this is an unnecessary annoyance.  We don't by default ask the 
> user any questions today, when they want to kill an Emacs session.

But Emacs *does* prompt the user today. If you call 
'save-buffers-kill-emacs' from an emacsclient frame, it will (almost) 
always ask you, "This Emacs session has clients; exit anyway?" My patch 
just gets rid of that annoyance when we can be sure it's unnecessary 
(i.e. it won't ask if there are no other emacsclients and no other 
frames not owned by a client).

The patch does also change the prompt to be more-precise when there is 
an open frame not owned by a client[1]. However, it doesn't add any new 
prompts where there were none before; it only removes a prompt in one case.

> What is the use case where this command could be invoked by mistake
> and will risk losing edits or other valuable work?

I didn't write this code initially, but here's my understanding of why 
the prompt is useful.

If you use "emacs --daemon", 'C-x C-c' ('save-buffers-kill-terminal') 
will only close the current emacsclient, not shut down the daemon 
entirely. If you'd like to shut down the daemon too, you can call 
'save-buffers-kill-emacs' instead. Maybe you'd even bind that to a key 
combo or do it automatically in some cases.

So given the above, imagine you're at the office. You start the Emacs 
daemon and connect a GUI emacsclient instance[2]. Then you do a bunch of 
work until it's time to go home, but you leave your emacsclient running 
to pick up where you left off the next day.

When you get home, you remember that you wanted to edit something 
quickly, so you SSH into you work computer and start a second 
emacsclient instance. By now, you forgot about your first emacsclient 
instance you made while at work. If you call 'save-buffers-kill-emacs' 
from your SSH emacsclient, it's nice that it can remind you that you 
have another emacsclient instance still running: since you don't see the 
GUI frames for the other client, it would be easy to forget about them 
and kill the session entirely. Then when you go into work the next day, 
the buffers you had open yesterday would be gone.

In this case, you likely haven't lost changes to any files, since you 
saved before killing the session, but you'd lose non-file buffers, 
window configuration, etc. (Of course, this assumes you're not using 
desktop.el.)

As for the code I added to check for non-client frames, the story is 
pretty much the same, although that code is there to handle situations 
where users start Emacs normally (i.e. by running "emacs") and then 
start the Emacs server via '(server-start)'. When connecting to that 
Emacs session remotely, it would be useful to get a prompt for the same 
reasons above. The only difference is that the GUI frames on your work 
system are "non-client" frames, so the code checks for them in a 
different way.

[1] Excluding the initial frame for "emacs --daemon", that is.

[2] This could be as simple as clicking the "Emacs (client)" icon on 
your desktop.




This bug report was last modified 2 years and 219 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.