bug#51993: 29.0.50; [PATCH] Killing emacsclient terminal with `server-stop-automatically' doesn't prompt to save files

[Jim Porter <jporterbugs@gmail.com>]

(Cc'ing Lars since he merged the previous patch, and I want to be sure 
everyone's on the same page here.)

On 11/23/2021 1:48 AM, Gregory Heytings wrote:
> This is not a bug, this is the intented behavior of that feature, which 
> was discussed on emacs-devel and in bug#51377.

I started that discussion[1] (and participated throughout it), and I 
don't think we actually agreed that this was the intended behavior. The 
closest I see is this:

On 10/24/2021 11:08 AM, Jim Porter wrote[2]:
> I don't think this is true in general. The docstring for
> `server-save-buffers-kill-terminal' says: "If emacsclient was started
> with a list of filenames to edit, then only these files will be asked to
> be saved." As a result, some files with unsaved changes may still exist,
> so we'd want to prompt about those *before* the last frame is closed.

However, I should stress that the case I brought up above is just a 
counterexample to show a problem with a previous implementation 
strategy, not a full specification. That's part of why I posted patches 
in bug#51377 in the hopes that an implementation would explain the 
behavior I intend more precisely than prose.

The current behavior on Emacs 29 certainly isn't what I personally 
intended when bringing the idea up on emacs-devel.

On 11/23/2021 1:48 AM, Gregory Heytings wrote:
> I attached a patch which preserves the intended behavior of that 
> feature, and adds a fourth possible behavior, the one Jim now wants.

I'm concerned that we're now up to 4 different behaviors, when I think 
two of them are just the result of a miscommunication between the two of 
us. The way I've interpreted our prior discussion is that you would 
prefer the daemon to be killed invisibly if there's no reason to keep it 
alive; this is the `empty' option in your patches. On the other hand, 
I'd prefer to the daemon to be killed "loudly" when there are no 
non-daemon frames left, including being prompted to save buffers, kill 
processes, etc in all the "usual" cases; this is `delete-last-frame' in 
your patch, plus a couple of other tweaks I have pending. (Note: Just to 
be clear, this isn't a specification; it's only a brief summary.)

I think your message to me in bug#51377 encapsulates this well:

On 10/24/2021 2:37 PM, Gregory Heytings wrote[3]:
> I see.  We have different mental models, I guess.  From my viewpoint
> the Emacs server should stay there until it's not necessary, and I'd be
> surprised to be queried about what to do with buffers opened of
> processes started in a frame I already closed when I want to close
> another frame. But of course I do not object to have both behaviors.

However, in your next two messages in the bug, you added:

On 10/26/2021 3:37 AM, Gregory Heytings wrote[4]:
> If it's now also necessary to kill the daemon when you close the
> last Emacs frame with the window manager close button (I did not see
> this requirement in your original post)...

On 10/26/2021 4:59 AM, Gregory Heytings wrote[5]:
> It just occurred to me that it's very easy to add a third behavior,
> namely the one you expect...

(The "third behavior" is the `delete-frame' option.) As I understand 
things, both the `kill-terminal' and `delete-frame' options were added 
to support my mental model in particular (we were the only two people 
commenting on the bug at that time). From my perspective, 
`kill-terminal` (and now `kill-last-terminal' as well) are just the 
result of some miscommunication between the two of us in bug#51377. 
Unless there's a strong argument for keeping them around, I think it 
would be best to remove them so that there are only 2 options (well, 3 
if you include the default behavior).

I hope the above explains things reasonably thoroughly for everyone 
(hence all the citations to previous discussions). If pressed, I could 
probably create a full specification of the behavior I'd like to see, 
but I find it quite a bit easier to explain by way of a patch. If anyone 
needs clarification on any of the above, just let me know and I'll try 
to elaborate.

[1] https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01465.html
[2] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02163.html
[3] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02207.html
[4] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02367.html
[5] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02373.html