From: Jim Porter <jporterbugs@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 58404@debbugs.gnu.org
Subject: 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 [thread overview]
Message-ID: <02eb7516-bccc-16ab-84f2-4688849bfba8@gmail.com> (raw)
In-Reply-To: <83k058i4y2.fsf@gnu.org>
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.
next prev parent reply other threads:[~2022-10-10 8:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-09 23:32 bug#58404: 29.0.50; [PATCH] When killing Emacs from the last client, don't warn about the session having clients Jim Porter
2022-10-10 6:11 ` Eli Zaretskii
2022-10-10 8:08 ` Jim Porter [this message]
2022-10-10 8:53 ` Eli Zaretskii
2022-10-10 16:43 ` Jim Porter
2022-10-10 16:59 ` Eli Zaretskii
2022-10-10 17:49 ` Jim Porter
2022-10-10 17:57 ` Eli Zaretskii
2022-10-10 23:09 ` Jim Porter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=02eb7516-bccc-16ab-84f2-4688849bfba8@gmail.com \
--to=jporterbugs@gmail.com \
--cc=58404@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).