unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Gregory Heytings <gregory@heytings.org>
To: Jim Porter <jporterbugs@gmail.com>
Cc: larsi@gnus.org, 51993@debbugs.gnu.org
Subject: bug#51993: 29.0.50; [PATCH] Killing emacsclient terminal with `server-stop-automatically' doesn't prompt to save files
Date: Tue, 23 Nov 2021 22:49:49 +0000	[thread overview]
Message-ID: <890d44ded2c42fe531a1@heytings.org> (raw)
In-Reply-To: <1623621b-d2a6-a68c-ac28-cdd371886b11@gmail.com>


>>> I should stress that the case I brought up above is just a 
>>> counterexample to show a problem with a previous implementation 
>>> strategy
>> 
>> Which problem?
>
> Prior to that comment, your proposed implementation would kill Emacs on 
> a timer when there were no non-daemon frames left, which could result in 
> unsaved changes to files being lost. I replied to point that out and 
> showed some steps to reproduce it: 
> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02163.html>.
>

I don't think it's useful to discuss a problem that was raised and fixed a 
month ago.

>
> If I'm understanding your patch, the behavior I'm looking for is 
> essentially a combination of `kill-terminal' and `delete-last-frame'.
>

If so, a fifth behavior could be implemented.  But you would have to 
describe what you want, and it should be something reasonable.  Could you 
please do that, and explain what you want when:

1. You delete a frame that is not the last one
2. You delete the last frame
3. You kill a terminal that is not the last one
4. You kill a terminal that is the last one

>
> I've specified the problems. I can try to clarify if there's any 
> confusion though. This bug is one such problem.
>

As I said earlier, the problem you described in this bug report was not a 
bug, at least in the sense that it was not something that was not 
explicitly intended by the one who wrote the code (and documented).  And 
the behavior you wanted is handled by the patch I sent, without removing 
any of the other existing behaviors.  But now you apparently want 
something else again.

>
> I don't think that a user who opts in to stopping the Emacs daemon 
> automatically is *also* opting in to changing the behavior of whether 
> Emacs will prompt about saving files when killing a (non-last) client. 
> Since there are other clients, the daemon won't be killed, and so the 
> behavior should be identical to what happens without 
> `server-stop-automatically'. As a user, I would find it very strange 
> that enabling `server-stop-automatically' would change Emacs' behavior 
> in ways *other than* stopping the server in certain cases.
>

Yet this is what you're asking.  If you want Emacs to prompt you whether 
the files should be saved and the process killed when you delete the last 
frame, you want to change the way Emacs prompts about saving files and 
killing processes, because this (namely prompting the user when the last 
frame is deleted) isn't happening without server-stop-automatically.





  reply	other threads:[~2021-11-23 22:49 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 [this message]
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
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

  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=890d44ded2c42fe531a1@heytings.org \
    --to=gregory@heytings.org \
    --cc=51993@debbugs.gnu.org \
    --cc=jporterbugs@gmail.com \
    --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 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).