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
next prev parent 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.