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

Previous Next

Package: emacs;

Reported by: Peter Ludemann <peter.ludemann <at> gmail.com>

Date: Mon, 23 May 2022 19:57:02 UTC

Severity: normal

Tags: wontfix

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Ludemann <peter.ludemann <at> gmail.com>
Cc: michael.albinus <at> gmx.de, 55599 <at> debbugs.gnu.org
Subject: bug#55599: save-buffers-kill-emacs doesn't give a visible prompt when called from command line
Date: Sat, 28 May 2022 22:25:53 +0300
> From: Peter Ludemann <peter.ludemann <at> gmail.com>
> Date: Sat, 28 May 2022 11:27:22 -0700
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, 55599 <at> debbugs.gnu.org
> 
> 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.

During startup of the daemon, it can still have its original standard
output/error streams (and even that is not guaranteed if it is not
invoked from the shell prompt), but once it starts, the standard
output/error streams are closed b y the system and are no longer
available, AFAIK.

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

yes-or-no-p needs to ask a question and get the response.

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

The terminal is still taken by the client frame it displays.




This bug report was last modified 1 year and 311 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.