bug#55599: save-buffers-kill-emacs doesn't give a visible prompt when called from command line

[Peter Ludemann]

It seems that there is a way to get an interactive message to the terminal in batch mode ...

    During daemon startup (with an existing .emacs.desktop file), I get this on my terminal:

        bunzip2ing contrib-protobufs-2021-06-07-15-56.tbz2... 
        bunzip2ing contrib-protobufs-2021-06-07-15-56.tbz2...done
        Parsing tar file...
        Parsing tar file...done
        Please type y, n, ! or i, or C-v/M-v to scroll: 

This seems to be from make-progress-reporter, which (if I read the code correctly) ends up calling (message "%s %s %s" text pulse-char suffix)). And that message displays interactively on the terminal.

So, there is a way to have the messages from emacsclient --eval display on the terminal, but in some (most?) situations they don't. (The definition for message says: "In batch mode, the message is printed to the standard error stream, followed by a newline.") So, I infer that yes-or-no-p should just use "message" and all will be fine. (Another example of a prompt that should go to the terminal but doesn't: "Active processes exist; kill them and exit anyway" should use "message".)

As to your suggested feature request: I'm not requesting termination of the server non-interactively - I'm just saying that when the shutdown command comes from the command line, the messages be output to the terminal, the way "message" does and not the way yes-or-no-p does.

On Tue, 24 May 2022 at 04:31, Eli Zaretskii <eliz@gnu.org> wrote:

> Cc: 55599@debbugs.gnu.org
> From: Peter Ludemann <peter.ludemann@gmail.com>
> 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).

"emacsclient -e" is not meant to support execution of interactive Lisp
programs, especially not when there's no client frame through which to
interact with the user.  If you want interaction via emacsclient,
start emacsclient normally, and then invoke those interactive Lisp
programs in the client frame that the server opens.

I see no bugs in the behavior you report, and no change from previous
Emacs versions.  So I'm unsure what issues are being discussed here
(but see below).

> 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.

You can do anything from the command line, as long as you make sure
the Lisp program you invoke via the -e switch doesn't ask any
questions.  E.g., you can invoke a Lisp program that deletes the
desktop lock file in a kill-emacs-hook, provided that you write such a
hook yourself and set it in the same Lisp program you pass via -e.

The change that triggered this bug report supports "normal" use of
emacsclient, whereby the server session is terminated interactively.
If you insist on doing that noninteractively, you will have to write
your own Lisp program to do that.  Alternatively, feel free to request
a new feature of emacsclient whereby you could terminate the server
session non-interactively via some new command-line option; then the
implementation of such a feature will have to do all that internally.