bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save

[Jim Porter <jporterbugs@gmail.com>]

On 10/31/2022 11:39 PM, Eli Zaretskii wrote:
>> Date: Mon, 31 Oct 2022 14:06:16 -0700
>> Cc: 58909@debbugs.gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>>
>> 1) For now, just make the change in my patch to 'delete-frame' in
>> src/frame.c to allow hooks in 'delete-frame-functions' to quit out of
>> frame deletion. That way, users who want the rest of the behavior in my
>> patch can just replace 'server-handle-delete-frame' with their own Elisp
>> function. This change isn't entirely without risk, since it could cause
>> some hooks to go from silently signaling an error to making it
>> impossible to delete frames, but I'm not sure that will come up in
>> practice (and if it does, the hooks can be fixed easily enough).
> 
> I don't see how this would serve well the use case you want to enable.
> We are talking about prompting the user to save unsaved buffers, yes?
> So adding a hook in server-delete-client sounds like a much better
> solution to me, as it doesn't affect the (much more general)
> delete-frame in any way.

I think a hook on 'server-delete-client' could work well. It'd make it 
easier to write hooks that run at the right time compared to using other 
existing hooks. In fact, I had a similar idea for bug#51993[1]. In that 
case I ended up adding 2 hooks to 'server-delete-client', but that was 
just to work around a strange bug I saw in testing; I could probably fix 
that in a better way with some more effort so that we only need one new 
hook.

However, I'm not sure how to do this in a complete way without tweaking 
'delete-frame-functions'. Deleting a frame can cause Emacs to delete the 
client if that was the last frame for the client; that's 
long-established behavior, so we shouldn't change it. But that poses a 
problem. If 1) I delete a frame, 2) it calls 'server-delete-client', and 
3) some 'server-delete-client-hook' prompts me, then I might try to quit 
out via C-g. Without my change to how 'delete-frame-functions' are run, 
then C-g would only quit out of 'server-delete-client', but would still 
delete the frame. At least for some emacsclient use cases, that could be 
a problem.

For example, suppose I have a system called "remotehost" with an "emacs 
--daemon" instance and EDITOR="emacsclient -c":

   me@localhost $ ssh -X remotehost
   ...
   me@remotehost $ git commit

   ;; emacsclient starts and creates a new frame on my local display.
   ;; Start editing the git commit message.
   ;; Get distracted, do some other stuff...

   ;; ... finish up the other stuff, click "X" on the emacsclient frame.
   Save file /home/me/src/project/.git/COMMIT_EDITMSG?
   ;; Realize, "Oh yeah! I forgot to finish this commit message."
   C-g

Without the 'delete-frame-functions' change, I'd now be left with no 
Emacs frames on my localhost, but the emacsclient is still running. That 
would be inconvenient, since I'd have to do more work to fix the 
situation. The best way I can think of would be to start another 
emacsclient locally, do the edits to COMMIT_EDITMSG, and then 'C-x #' to 
finish editing. It'd be a lot nicer if 'C-g' stopped the frame from 
getting deleted. (Incidentally, that's how it would work in a regular, 
non-client/server Emacs. Clicking "X" on the last frame actually calls 
'save-buffer-kill-emacs' instead of 'delete-frame', and you can 'C-g' 
out of that to keep the frame open.)

> You can start the discussion now, from my POV.  But if having a hook
> in server-delete-client is good enough, I don't see why we would need
> to discuss an actual behavior change.

Yeah, let's finish up the discussion here, and if I have any open 
questions that could use a wider audience, I'll post to emacs-devel 
afterwards.

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg00908.html