bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#51993: 29.0.50; [PATCH] Killing emacsclient terminal with `server-st


From: Eli Zaretskii
Subject: bug#51993: 29.0.50; [PATCH] Killing emacsclient terminal with `server-stop-automatically' doesn't prompt to save files
Date: Fri, 21 Oct 2022 09:38:19 +0300

> Date: Thu, 20 Oct 2022 22:51:42 -0700
> Cc: larsi@gnus.org, 51993@debbugs.gnu.org, gregory@heytings.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> >>     b) if this *is* the last client, prompt the user to save everything
> >> (as with 'save-buffers-kill-emacs'), and then delete the client + kill
> >> the Emacs daemon.
> > 
> > You mean, in b), instead of just deleting the frame and leaving the
> > daemon run, you want to shut down Emacs in its entirety, as if the
> > user invoked kill-emacs?  I'm okay with that as an optional behavior,
> > although I myself won't use it, as it's too dangerous.
> 
> Almost. I'd like it to be as if the user invoked 
> 'save-buffers-kill-emacs'; that is, before killing Emacs, prompt the 
> user about everything[1] that might be lost by killing Emacs.

That should already happen, if you just call save-buffers-kill-emacs
in that case, right?

> This already exists as an option -- (server-stop-automatically 
> 'delete-frame)[2], but I also find the current behavior too dangerous. 
> My original message outlines one of the problems with the current 
> implementation: it changes the behavior of (a) in my description above.
> 
> >   $ emacs -Q --daemon
> >   $ emacsclient -a "" -c foo.txt
> >   $ emacsclient -a "" -c bar.txt
> > 
> >   ;; In the first client frame:
> >   foobar ;; Insert some text
> >   C-x C-c
> >   ;; Emacs prompts "Save file /path/to/foo.txt?..."
> > 
> > Now try the above, but call `(server-stop-automatically 'delete-frame)' 
> > first (or replace `delete-frame' with `kill-terminal'; it doesn't matter). 
> > In this case, Emacs doesn't prompt to save the file.

I'm not sure I see the direct relevance, and I don't think I see a bug
in the above behavior.  I'm probably missing something, but what?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]