all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.