unofficial mirror of bug-gnu-emacs@gnu.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 17:10:38 -0800	[thread overview]
Message-ID: <f5f36c4d-3100-e40f-b2e2-30c643106d9f@gmail.com> (raw)
In-Reply-To: <890d44ded244c5e34000@heytings.org>

On 11/23/2021 3:59 PM, Gregory Heytings wrote:
>>
>> 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.
>>
> 
> That's not what you did, you posted a patch claiming that one of the 
> existing behaviors had a bug and should be replaced with another one.

That's in reference to my original message on Oct 19[1], which I cited 
earlier in the paragraph that you excerpted the quote from. At the time, 
I said:

> I didn't see any options to configure this behavior in Emacs, but 
> looking over the code, it shouldn't be that hard for me to write a patch 
> to add this as an option. Before I started though, I wanted to see what 
> others thought. Is this a behavior others would be interested in? If so, 
> are there any other particulars I should take into account in my patch?

--------------------

On 11/23/2021 3:59 PM, Gregory Heytings wrote:
>> you've instead implemented the behavior "for" me
>>
> 
> That's not what I did, I tried to implement a function that provides 
> different possible behaviors corresponding to different needs and 
> expectations, not just the behavior you expected.  And I did this based 
> on your feedback, what others said on emacs-devel, and my own feelings.  
> I hoped (and thought until today) that the behavior you expected was one 
> of them.

And that's fine. I have no issue supporting behaviors other than the one 
I personally want. (For example, I have no problem with the `empty' 
behavior, even though I wouldn't personally find it useful.) However, I 
also want to be sure that we don't provide *unnecessarily* many options 
here, since that adds to the maintenance burden and may produce 
unexpected behavior for users if they don't quite understand the 
distinction between each possible setting.

In this case, I think it's better to continue prompting users when 
killing a non-last client just like Emacs 28[2] does. There might be 
some value in avoiding that prompt, but I think a user who *doesn't* use 
`server-stop-automatically' is just as likely to want that behavior, so 
if we want to support that, we should provide a separate configuration 
option to do so.

In particular, I think it's valuable to prompt users in this case 
because it comes up when using emacsclient and committing code. If I set 
`EDITOR="emacsclient -c"' and run `git commit', then under Emacs 28, I 
can close the client with `C-x C-c'[3] and it will prompt me if I forgot 
to save the commit message. That's useful because without the prompt, it 
would (usually) just abort the commit due to an empty message.

I think that behavior is worth preserving. (Likewise, I think it's worth 
preserving the ability to keep all your open frames by pressing C-g if 
Emacs prompts you about saving files when you try to kill a client.) 
Thus, I implemented the patch that you can see in the original message.

--------------------

In addition, I'm not certain that we need both `delete-frame' (or 
`delete-last-frame' as it's called in your latest patch) and 
`kill-terminal'. The only difference between the two is that in the 
former, individually closing the last non-daemon frame (e.g. by `C-x 5 
0' or clicking the X on the frame's titlebar) also kills the daemon. I 
prefer the behavior of `delete-frame', since my mental model is that the 
daemon should be killed *whenever* the last non-daemon frame is closed, 
no matter *how* it's closed. Maybe someone has a strong opinion in the 
other direction and actively wants the `kill-terminal' behavior instead. 
I don't have a problem with keeping that option around if someone would 
actually use it, but I'm skeptical of that. In this case though, I'm 
happy to present my argument and then defer to the Emacs maintainers to 
make the final call, whatever that may be. If it stays, that's fine with 
me; if it goes, that's fine too.

--------------------

Since, as you mentioned before, we have different mental models for how 
this works, I'm mainly trying to explain through both prose and patches 
how this should work under my mental model. If I understand your prior 
messages correctly, your mental model is best encapsulated by the 
`empty' configuration. I'm 100% happy to keep that around as-is, even 
though it's not my preferred solution. However, my preferred solution is 
"something close to `delete-frame'".

Your patch in bug#51377 gets most of the way to what I wanted, but there 
are a couple of corner cases that don't work like I expect, hence this 
bug. Whether the behavior is a true "bug", a miscommunication, or 
something else doesn't matter much to me. All I'm looking for is 
something along the following lines (note: this isn't 100% rigorous, so 
don't take it as a precise specification):

1) When killing a non-last client (including by closing the last of its 
frames), the behavior should be exactly the same as the default 
emacsclient behavior. (That's what this bug is about.)

2) When killing the last client (including by closing the last of its 
frames), the behavior should be exactly the same as killing Emacs when 
*not* using a server. (Roughly speaking, that means calling 
`save-buffers-kill-emacs'. It would also be nice to have an option to 
silence the "This Emacs session has clients; exit anyway?" prompt, 
though I can certainly understand others wanting to keep it around in 
this case.)

Again, that may not be 100% precise, but it's the mental model I've used 
while implementing patches for this on my end. The specific 
implementation I use has shifted somewhat over time as I find corner 
cases, and also through consulting your patches. Using 
`delete-frame-functions' as in your code greatly simplified my 
implementation, for example. Thanks for that.

Hopefully my delays in following up on bug#51377 haven't been *too* 
disruptive. As mentioned, I was unfortunately too busy to devote 
sufficient time to it back then (my plan when posting to emacs-devel was 
just to collect feedback and to work on the implementation slowly over 
the next several weeks). Now my schedule is a bit less hectic, and I'm 
hoping to address the last few concerns I had after taking the time to 
test things out more thoroughly.

I'm certainly not trying to step on your toes or undo your patch. Just 
to account for certain corner cases that I didn't have a chance to 
investigate (or resolve) at the time.

[1] https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01465.html
[2] Or without `server-stop-automatically'
[3] You could also use `C-x #' here, but I find `C-x C-c' easier to 
type, so prefer the latter in cases where either would do what I want.





  reply	other threads:[~2021-11-24  1:10 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 [this message]
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=f5f36c4d-3100-e40f-b2e2-30c643106d9f@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 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).