|
From: | Jim Porter |
Subject: | bug#58909: 29.0.50; [WIP PATCH] Deleting the last frame of an emacsclient doesn't ask to save |
Date: | Tue, 1 Nov 2022 09:11:40 -0700 |
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-gWithout 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
[Prev in Thread] | Current Thread | [Next in Thread] |