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

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

bug#55599: save-buffers-kill-emacs doesn't give a visible prompt when ca


From: Peter Ludemann
Subject: bug#55599: save-buffers-kill-emacs doesn't give a visible prompt when called from command line
Date: Tue, 24 May 2022 02:29:37 -0700

I don't want to unconditionally save buffers; I want to conditionally save them. (Actually, I wouldn't mind if it didn't save the buffers at all; when I restart emacs, it finds the ".#" files, and that suffices.)

There's a more general problem here (although you might decide it's too much trouble to fix) -- it seems that when "emacsclient -e" is used, any prompts go to the non-existent screen rather than to the terminal. (e.g., yes-or-n-p's prompt).

Also, save-buffers-kill-emacs does two things: (conditionally) saves the buffers and deletes the ~/.emacs.d/.emacs.desktop.lock file. On the other hand, the lower level kill-emacs doesn't delete the lock file (and the response to bug 55560 is that that's a deliberate design decision). So, there's no way of doing from the command line "kill-emacs-and-remove-lock-file", it seems.

On Tue, 24 May 2022 at 00:34, Michael Albinus <michael.albinus@gmx.de> wrote:
Peter Ludemann <peter.ludemann@gmail.com> writes:

Hi Peter,

> When I try to kill an emacs server from the command line by:
>    emacsclient -e '(save-buffers-kill-emacs)'
> nothing appears to happen if there are any unsaved buffers.
>
> I presume that this is because the prompt goes to the usual place (below
> the mode line in the screen), which of course isn't visible from the
> command line because there isn't any screen when using "emacsclient -e".
>
> This is a follow-up to bug 55560, where it was suggested that kill-emacs is
> inappropriate and instead I should use save-buffers-kill-emacs.

There is an optional ARG which lets Emacs silently save all file-visiting
buffers without asking. So you must call

  emacsclient -e '(save-buffers-kill-emacs t)'

Best regards, Michael.

reply via email to

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