all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jim Porter <jporterbugs@gmail.com>
To: Gregory Heytings <gregory@heytings.org>
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 15:42:59 -0800	[thread overview]
Message-ID: <60d6439a-d2be-cbb4-b979-312a35216758@gmail.com> (raw)
In-Reply-To: <890d44ded2c42fe531a1@heytings.org>

Eli, Lars: I'm not sure what either of you would like to do about this 
bug, but it seems that most of the conflict is due to a miscommunication 
between me and Gregory (that's my impression, anyway). I hope my 
previous messages have explained my thoughts on the matter fairly 
thoroughly (if not, just let me know). However, I'm not sure there's 
much more I can add to the discussion beyond this message.

On 11/23/2021 2:49 PM, Gregory Heytings wrote:
> 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've only wanted one behavior since I started this discussion on Oct 
19[1]. However, rather than making sure we understand each other's 
descriptions (or consulting the patches I've posted throughout the 
discussion) and have properly identified the corner cases to handle, 
you've instead implemented the behavior "for" me, even though I said 
from the beginning that I was looking to write the patch myself. I never 
posted a rigorous specification of the behavior I wanted for that 
reason: I was soliciting feedback to develop a patch that meets my needs 
(along with the needs of anyone who spoke up at the time, if possible).

The fact that you opted to help by authoring your own patches is 
appreciated, but it ultimately doesn't help me because we seem to be 
talking at cross purposes and your impressions of what I want aren't 
what I actually want. Moreover, if our interpretations *don't* match up 
and I bring up an issue with a proposed patch, that doesn't mean that I 
want an additional option or that I've changed my mind; it just means 
that we haven't reached an understanding yet.

I certainly don't expect you to do any additional work here. I'm 
perfectly happy to provide patches implementing the behavior I have in 
mind, and to adjust them as needed if you or anyone else has feedback on 
them. While I could probably construct a rigorous specification for the 
behavior I want so that someone else (e.g. you) could implement it, that 
would probably end up just being a set of test cases extracted from the 
patch I already have.

As an aside, I mentioned this previously, but I think it would be 
valuable to write some automated test cases to verify that things work 
as expected. However, I didn't see a way to test creating/destroying 
Emacs servers/clients via ERT. I'm certainly open to doing so if someone 
points me in the right direction though.

>> 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.

That's not relevant to the case I'm discussing above. I specifically 
said I'm talking about the behavior when killing the *non-last* client. 
In that case, the server won't be stopped, no matter how 
`server-stop-automatically' is configured.

[1] https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01465.html





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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=60d6439a-d2be-cbb4-b979-312a35216758@gmail.com \
    --to=jporterbugs@gmail.com \
    --cc=51993@debbugs.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.