GNU bug report logs -
#51993
29.0.50; [PATCH] Killing emacsclient terminal with `server-stop-automatically' doesn't prompt to save files
Previous Next
Reported by: Jim Porter <jporterbugs <at> gmail.com>
Date: Sat, 20 Nov 2021 04:30:01 UTC
Severity: normal
Tags: patch
Found in version 29.0.50
Done: Jim Porter <jporterbugs <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #14 received at 51993 <at> debbugs.gnu.org (full text, mbox):
(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
This bug report was last modified 2 years and 163 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.