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: larsi@gnus.org, 51993@debbugs.gnu.org, gregory@heytings.org
Subject: bug#51993: 29.0.50; [PATCH] Killing emacsclient terminal with `server-stop-automatically' doesn't prompt to save files
Date: Fri, 21 Oct 2022 20:46:47 -0700	[thread overview]
Message-ID: <2738f071-c87f-72cf-226f-6e8597cb07a8@gmail.com> (raw)
In-Reply-To: <83h6zxwujo.fsf@gnu.org>

On 10/20/2022 11:38 PM, Eli Zaretskii wrote:
>> Date: Thu, 20 Oct 2022 22:51:42 -0700
>> Cc: larsi@gnus.org, 51993@debbugs.gnu.org, gregory@heytings.org
>> From: Jim Porter <jporterbugs@gmail.com>
>>
>>>>      b) if this *is* the last client, prompt the user to save everything
>>>> (as with 'save-buffers-kill-emacs'), and then delete the client + kill
>>>> the Emacs daemon.
>>>
>>> You mean, in b), instead of just deleting the frame and leaving the
>>> daemon run, you want to shut down Emacs in its entirety, as if the
>>> user invoked kill-emacs?  I'm okay with that as an optional behavior,
>>> although I myself won't use it, as it's too dangerous.
>>
>> Almost. I'd like it to be as if the user invoked
>> 'save-buffers-kill-emacs'; that is, before killing Emacs, prompt the
>> user about everything[1] that might be lost by killing Emacs.
> 
> That should already happen, if you just call save-buffers-kill-emacs
> in that case, right?

Yeah. My expectation is that I can type 'C-x C-c' (or 'M-x 
save-buffers-kill-terminal') to kill a client, and if it's the last 
client, instead kill Emacs entirely (like 'M-x 
save-buffers-kill-emacs'). So roughly speaking, the change would be that 
you can set 'save-buffer-kill-terminal' to work like 
'save-buffer-kill-emacs' when there's only 1 client left.

>> This already exists as an option -- (server-stop-automatically
>> 'delete-frame)[2], but I also find the current behavior too dangerous.
>> My original message outlines one of the problems with the current
>> implementation: it changes the behavior of (a) in my description above.
>>
>>>    $ emacs -Q --daemon
>>>    $ emacsclient -a "" -c foo.txt
>>>    $ emacsclient -a "" -c bar.txt
>>>
>>>    ;; In the first client frame:
>>>    foobar ;; Insert some text
>>>    C-x C-c
>>>    ;; Emacs prompts "Save file /path/to/foo.txt?..."
>>>
>>> Now try the above, but call `(server-stop-automatically 'delete-frame)' first (or replace `delete-frame' with `kill-terminal'; it doesn't matter). In this case, Emacs doesn't prompt to save the file.
> 
> I'm not sure I see the direct relevance, and I don't think I see a bug
> in the above behavior.  I'm probably missing something, but what?

The issue in the quote above is that if you enable automatic server 
shutdown in Emacs 29, it changes the behavior of exiting an emacsclient 
even when it wouldn't stop the server (i.e. when there are other active 
clients). That's surprising to me, I wouldn't expect that setting to 
affect cases when it decides *not* to kill the Emacs daemon.

(This is relevant to the previous discussion since fixing this would get 
Emacs's automatic server shutdown - aka killing the daemon - close to 
the way I described there. Gregory mentioned[1] that the current 
behavior is intended, although we've had some difficulty coming to an 
agreement on how all this should work. Hence why I thought a hook might 
help here: if there are strong opinions in various directions, maybe a 
simple option isn't enough. Or maybe this is a case where you and/or 
Lars would be in a better position to make a final decision...)

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51993





  reply	other threads:[~2022-10-22  3:46 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-20  4:29 bug#51993: 29.0.50; [PATCH] Killing emacsclient terminal with `server-stop-automatically' doesn't prompt to save files Jim Porter
2021-11-20  7:13 ` Eli Zaretskii
2021-11-23  9:48   ` Gregory Heytings
2021-11-23 18:25     ` Jim Porter
2021-11-23 20:37       ` Gregory Heytings
2021-11-23 22:08         ` Jim Porter
2021-11-23 22:49           ` Gregory Heytings
2021-11-23 23:42             ` Jim Porter
2021-11-23 23:59               ` Gregory Heytings
2021-11-24  1:10                 ` Jim Porter
2021-11-29  5:39 ` Jim Porter
2021-11-29 12:41   ` Eli Zaretskii
2021-11-29 13:40     ` Gregory Heytings
2021-11-29 19:31       ` Jim Porter
2022-01-01  0:11         ` Jim Porter
2022-09-09 17:55       ` Lars Ingebrigtsen
2022-09-09 18:04         ` Jim Porter
2022-10-09 22:09           ` Jim Porter
2022-10-10  6:04             ` Eli Zaretskii
2022-10-20  3:14               ` Jim Porter
2022-10-20  6:23                 ` Eli Zaretskii
2022-10-21  5:51                   ` Jim Porter
2022-10-21  6:38                     ` Eli Zaretskii
2022-10-22  3:46                       ` Jim Porter [this message]
2022-10-22  6:57                         ` Eli Zaretskii
2022-10-25  3:10                           ` Jim Porter
2022-10-30 22:32                             ` Jim Porter
2022-11-29  5:31                             ` Jim Porter
2022-12-01 17:29                               ` Eli Zaretskii
2022-12-02  1:09                                 ` bug#51993: 29.0.50; [PATCH for 29.1] " Jim Porter
2022-12-02 14:10                                   ` Eli Zaretskii
2022-12-02 21:33                                     ` Jim Porter
2022-12-04 17:56                                       ` Eli Zaretskii
2022-12-04 22:26                                         ` Jim Porter
2022-12-06 22:20                                           ` Jim Porter
2022-12-02  1:42                                 ` bug#51993: 29.0.50; [PATCH explanation] " Jim Porter
2022-12-02 14:31                                   ` Eli Zaretskii
2021-11-29 19:12     ` bug#51993: 29.0.50; [PATCH] " 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=2738f071-c87f-72cf-226f-6e8597cb07a8@gmail.com \
    --to=jporterbugs@gmail.com \
    --cc=51993@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=gregory@heytings.org \
    --cc=larsi@gnus.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.