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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55599 in the body.
You can then email your comments to 55599 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Ludemann <peter.ludemann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: save-buffers-kill-emacs doesn't give a visible prompt when called
 from command line
Date: Mon, 23 May 2022 12:56:17 -0700

[Message part 1 (text/plain, inline)]

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.

Probably not relevant, but including for completeness:

I have the following "my-exit" function added to
kill-emacs-query-functions; I've confirmed that this use of daemonp behaves
as expected and that the "Really kill Emacs?" prompt doesn't happen:

(defun my-exit ()
  (or (daemonp)
      (yes-or-no-p "Really kill Emacs? ")))


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll
bars)
 of 2022-05-21 built on penguin
Repository revision: 208102fa470e3417320062cdb48a9967d80bf092
Repository branch: master
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --prefix=/home/peter/.local --with-gnutls
 PKG_CONFIG_PATH=/home/peter/.local/lib/pkgconfig:'

Configured features:
FREETYPE GIF GMP GNUTLS JPEG LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XAW3D XDBE
XFT XIM XPM LUCID ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Apropos

Minor modes in effect:
  global-auto-revert-mode: t
  display-time-mode: t
  savehist-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
~/src/pykythe/emacs/prolog hides
/home/peter/.local/share/emacs/29.0.50/lisp/progmodes/prolog

Features:
(shadow sort mail-extr emacsbug message yank-media rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils shortdoc help-fns radix-tree misearch
multi-isearch mule-util apropos time-date term/xterm xterm finder-inf
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars cl-extra help-mode seq gv subr-x
byte-opt bytecomp byte-compile cconv autorevert filenotify grep compile
text-property-search comint ansi-color ring cus-load time savehist
desktop frameset cl-loaddefs cl-lib iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice simple cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads inotify
dynamic-setting font-render-setting x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 91186 8875)
 (symbols 48 9960 1)
 (strings 32 29163 1620)
 (string-bytes 1 904097)
 (vectors 16 15493)
 (vector-slots 8 175522 6636)
 (floats 8 79 477)
 (intervals 56 533 0)
 (buffers 992 12))

[Message part 2 (text/html, inline)]

Message #8 received at 55599 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Peter Ludemann <peter.ludemann <at> gmail.com>
Cc: 55599 <at> debbugs.gnu.org
Subject: Re: bug#55599: save-buffers-kill-emacs doesn't give a visible
 prompt when called from command line
Date: Tue, 24 May 2022 09:34:57 +0200

Peter Ludemann <peter.ludemann <at> 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.

Message #11 received at 55599 <at> debbugs.gnu.org (full text, mbox):

From: Peter Ludemann <peter.ludemann <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 55599 <at> debbugs.gnu.org
Subject: Re: 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

[Message part 1 (text/plain, inline)]

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 <at> gmx.de>
wrote:

> Peter Ludemann <peter.ludemann <at> 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.
>

[Message part 2 (text/html, inline)]

Message #14 received at 55599 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#55599: save-buffers-kill-emacs doesn't give a visible prompt
 when called from command line
Date: Tue, 24 May 2022 14:31:16 +0300

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

Message #17 received at 55599 <at> debbugs.gnu.org (full text, mbox):

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

[Message part 1 (text/plain, inline)]

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 <at> gnu.org> wrote:

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

[Message part 2 (text/html, inline)]

Message #20 received at 55599 <at> debbugs.gnu.org (full text, mbox):

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

Message #23 received at 55599 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: peter.ludemann <at> gmail.com
Cc: michael.albinus <at> gmx.de, 55599 <at> debbugs.gnu.org
Subject: Re: bug#55599: save-buffers-kill-emacs doesn't give a visible prompt
 when called from command line
Date: Sat, 28 May 2022 22:39:13 +0300

> Cc: michael.albinus <at> gmx.de, 55599 <at> debbugs.gnu.org
> Date: Sat, 28 May 2022 22:25:53 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > 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.

Sorry, that was incorrect, because I was confused about the situation
to which you were alluding.

The correct response is: when a daemon Emacs doesn't show any frames,
it has no way of communicating with the user, because the standard
streams are no longer available, AFAIK.

Message #26 received at 55599 <at> debbugs.gnu.org (full text, mbox):

From: Peter Ludemann <peter.ludemann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 55599 <at> debbugs.gnu.org
Subject: Re: bug#55599: save-buffers-kill-emacs doesn't give a visible prompt
 when called from command line
Date: Tue, 31 May 2022 12:34:23 -0700

[Message part 1 (text/plain, inline)]

There's probably a solution to this, but it could be a lot of work for a
small benefit.

If emacsclient --eval could pass in the stdin/stdout/stderr from the
terminal to the daemon, then things would work as I expect. But the
work-around is easy: emacsclient -c -e '...'

However, I noticed that stderr appears to be available, when there's an
error:

$ emacsclient --eval '(man fprintf)'
*ERROR*: Symbol’s value as variable is void: fprintf

and also when it works properly:

$ emacsclient --eval "(list-buffers)"
#<window 194 on *Buffer List*>




On Sat, 28 May 2022 at 12:39, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Cc: michael.albinus <at> gmx.de, 55599 <at> debbugs.gnu.org
> > Date: Sat, 28 May 2022 22:25:53 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> >
> > > 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.
>
> Sorry, that was incorrect, because I was confused about the situation
> to which you were alluding.
>
> The correct response is: when a daemon Emacs doesn't show any frames,
> it has no way of communicating with the user, because the standard
> streams are no longer available, AFAIK.
>

[Message part 2 (text/html, inline)]

Message #29 received at 55599 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#55599: save-buffers-kill-emacs doesn't give a visible prompt
 when called from command line
Date: Wed, 01 Jun 2022 05:30:39 +0300

> From: Peter Ludemann <peter.ludemann <at> gmail.com>
> Date: Tue, 31 May 2022 12:34:23 -0700
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, 55599 <at> debbugs.gnu.org
> 
> There's probably a solution to this, but it could be a lot of work for a small benefit.

Could you please describe the problem for which you are looking for a
solution?  During this discussion, you presented several issues that
bothered you, so I'm no longer sure which of those we are now talking
about.

> However, I noticed that stderr appears to be available, when there's an error:
> 
> $ emacsclient --eval '(man fprintf)'
> *ERROR*: Symbol’s value as variable is void: fprintf
> 
> and also when it works properly:
> 
> $ emacsclient --eval "(list-buffers)"
> #<window 194 on *Buffer List*>

That's emacsclient's stderr, not that of the daemon.  And it can only
print messages, not receive input.

Message #32 received at 55599 <at> debbugs.gnu.org (full text, mbox):

From: Peter Ludemann <peter.ludemann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 55599 <at> debbugs.gnu.org
Subject: Re: bug#55599: save-buffers-kill-emacs doesn't give a visible prompt
 when called from command line
Date: Wed, 1 Jun 2022 10:54:02 -0700

[Message part 1 (text/plain, inline)]

As Eli requested, restating what I'm asking ...

I start the emacs daemon from a terminal by:
    emacs --daemon

During startup, there might be some prompts (e.g., I get a
pagination prompt from parsing a tar file, when emacs is loading my last
session's files), and I can deal with them at the terminal.

When I shutdown the emacs daemon, I would like to also do this at the
terminal:
    emacsclient -e '(save-buffers-kill-emacs)'
but that doesn't work if there are any prompts (e.g., saving a file or
killing a shell process).
A work-around is to do:
    emacsclient -c -e '(save-buffers-kill-emacs)'
and that lets me see the prompts in the minibuffer.

However, it seems that "emacsclient -e" has access to the terminal's stderr.
Evidence: I get an error message at the terminal (not in a minibuffer) if I
do something with an error, such as
    emacsclient -e '(man fprintf)'

If stderr is being passed in to the evaluation code in daemon mode, then it
would be nice to also have stdin passed in, which would allow interaction
at the terminal.

However, this is a fairly minor improvement, given that "emacsclient -c -e"
works as expected, so probably it's not worth spending time on. (And the
documentation/emacswiki could be improved so that other people like me
don't bother you.)


On Tue, 31 May 2022 at 19:30, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Peter Ludemann <peter.ludemann <at> gmail.com>
> > Date: Tue, 31 May 2022 12:34:23 -0700
> > Cc: Michael Albinus <michael.albinus <at> gmx.de>, 55599 <at> debbugs.gnu.org
> >
> > There's probably a solution to this, but it could be a lot of work for a
> small benefit.
>
> Could you please describe the problem for which you are looking for a
> solution?  During this discussion, you presented several issues that
> bothered you, so I'm no longer sure which of those we are now talking
> about.
>
> > However, I noticed that stderr appears to be available, when there's an
> error:
> >
> > $ emacsclient --eval '(man fprintf)'
> > *ERROR*: Symbol’s value as variable is void: fprintf
> >
> > and also when it works properly:
> >
> > $ emacsclient --eval "(list-buffers)"
> > #<window 194 on *Buffer List*>
>
> That's emacsclient's stderr, not that of the daemon.  And it can only
> print messages, not receive input.
>

[Message part 2 (text/html, inline)]

Message #35 received at 55599 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#55599: save-buffers-kill-emacs doesn't give a visible prompt
 when called from command line
Date: Wed, 01 Jun 2022 22:52:11 +0300

> From: Peter Ludemann <peter.ludemann <at> gmail.com>
> Date: Wed, 1 Jun 2022 10:54:02 -0700
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, 55599 <at> debbugs.gnu.org
> 
> I start the emacs daemon from a terminal by:
>     emacs --daemon
> 
> During startup, there might be some prompts (e.g., I get a pagination prompt from parsing a tar file, when
> emacs is loading my last session's files), and I can deal with them at the terminal.
> 
> When I shutdown the emacs daemon, I would like to also do this at the terminal:
>     emacsclient -e '(save-buffers-kill-emacs)'
> but that doesn't work if there are any prompts (e.g., saving a file or killing a shell process).
> A work-around is to do:
>     emacsclient -c -e '(save-buffers-kill-emacs)'
> and that lets me see the prompts in the minibuffer.
> 
> However, it seems that "emacsclient -e" has access to the terminal's stderr.
> Evidence: I get an error message at the terminal (not in a minibuffer) if I do something with an error, such as
>     emacsclient -e '(man fprintf)'
> 
> If stderr is being passed in to the evaluation code in daemon mode, then it would be nice to also have stdin
> passed in, which would allow interaction at the terminal.

stderr is not passed.  What happens is that any messages sent by the
server are echoed by the client on its own stderr.

However, the reverse direction is not supported.  For it to be
supported, we need a way to tell the server to wait for the client to
return the user's response.  Such a feature doesn't exist, AFAIK, so
to support it we need to extend the client-server protocol.

Message #38 received at 55599 <at> debbugs.gnu.org (full text, mbox):

From: Peter Ludemann <peter.ludemann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 55599 <at> debbugs.gnu.org
Subject: Re: bug#55599: save-buffers-kill-emacs doesn't give a visible prompt
 when called from command line
Date: Wed, 1 Jun 2022 13:04:42 -0700

[Message part 1 (text/plain, inline)]

On Wed, 1 Jun 2022 at 12:52, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Peter Ludemann <peter.ludemann <at> gmail.com>
> > Date: Wed, 1 Jun 2022 10:54:02 -0700
> > Cc: Michael Albinus <michael.albinus <at> gmx.de>, 55599 <at> debbugs.gnu.org
> >
> > I start the emacs daemon from a terminal by:
> >     emacs --daemon
> >
> > During startup, there might be some prompts (e.g., I get a pagination
> prompt from parsing a tar file, when
> > emacs is loading my last session's files), and I can deal with them at
> the terminal.
> >
> > When I shutdown the emacs daemon, I would like to also do this at the
> terminal:
> >     emacsclient -e '(save-buffers-kill-emacs)'
> > but that doesn't work if there are any prompts (e.g., saving a file or
> killing a shell process).
> > A work-around is to do:
> >     emacsclient -c -e '(save-buffers-kill-emacs)'
> > and that lets me see the prompts in the minibuffer.
> >
> > However, it seems that "emacsclient -e" has access to the terminal's
> stderr.
> > Evidence: I get an error message at the terminal (not in a minibuffer)
> if I do something with an error, such as
> >     emacsclient -e '(man fprintf)'
> >
> > If stderr is being passed in to the evaluation code in daemon mode, then
> it would be nice to also have stdin
> > passed in, which would allow interaction at the terminal.
>
> stderr is not passed.  What happens is that any messages sent by the
> server are echoed by the client on its own stderr.
>
> However, the reverse direction is not supported.  For it to be
> supported, we need a way to tell the server to wait for the client to
> return the user's response.  Such a feature doesn't exist, AFAIK, so
> to support it we need to extend the client-server protocol.
>

That sounds like a lot of work for a very small pay-off (at least, in the
scenario I've given), especially as there's an easy work-around.
Feel free to close this bug/feature-request as "wontfix". ;)

And, again, thank-you for your prompt and very helpful responses (and your
patience with someone who knows very little about the internals of emacs)

[Message part 2 (text/html, inline)]

Message #41 received at 55599 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Peter Ludemann <peter.ludemann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Michael Albinus <michael.albinus <at> gmx.de>,
 55599 <at> debbugs.gnu.org
Subject: Re: bug#55599: save-buffers-kill-emacs doesn't give a visible prompt
 when called from command line
Date: Tue, 12 Sep 2023 18:43:03 -0700

tags 55599 + wontfix
close 55599
thanks

Peter Ludemann <peter.ludemann <at> gmail.com> writes:

> Feel free to close this bug/feature-request as "wontfix". ;)

Done.  Thanks for the bug report.

Previous Next

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