From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Peter Ludemann Newsgroups: gmane.emacs.bugs Subject: 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-ID: References: <87r14jo02m.fsf@gmx.de> <83k0ab5fqz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000010cd4205e0169528" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7965"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Albinus , 55599@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 28 20:29:12 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nv1BW-0001vg-RY for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 May 2022 20:29:10 +0200 Original-Received: from localhost ([::1]:47716 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nv1BV-00008X-8k for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 May 2022 14:29:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50182) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nv1BO-00008K-4L for bug-gnu-emacs@gnu.org; Sat, 28 May 2022 14:29:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44979) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nv1BN-0003Gi-S1 for bug-gnu-emacs@gnu.org; Sat, 28 May 2022 14:29:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nv1BN-0003qx-Nc for bug-gnu-emacs@gnu.org; Sat, 28 May 2022 14:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Peter Ludemann Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 May 2022 18:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55599 X-GNU-PR-Package: emacs Original-Received: via spool by 55599-submit@debbugs.gnu.org id=B55599.165376248814746 (code B ref 55599); Sat, 28 May 2022 18:29:01 +0000 Original-Received: (at 55599) by debbugs.gnu.org; 28 May 2022 18:28:08 +0000 Original-Received: from localhost ([127.0.0.1]:38876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nv1AW-0003pl-2L for submit@debbugs.gnu.org; Sat, 28 May 2022 14:28:08 -0400 Original-Received: from mail-pl1-f177.google.com ([209.85.214.177]:38703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nv1AS-0003pF-9c for 55599@debbugs.gnu.org; Sat, 28 May 2022 14:28:06 -0400 Original-Received: by mail-pl1-f177.google.com with SMTP id n18so6890284plg.5 for <55599@debbugs.gnu.org>; Sat, 28 May 2022 11:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=afE7Vxr8qLdVdkTUy6lxZoRfRPFBIqJx7vvUGWXU1Bg=; b=HGFDO6ioH707aaa/N9pbyKahLcIxgXzvzwqThqqSjYXL7rWcH21ZsPDllJv4M8ZMVR 89KBAFCk3PWb1/YcgW6zxSOIFn7q+lm+VTR/VbctMr+vkZ0ZMCBCtshOnRtyNPCgUtCd TWRmyvnCTh5DEp4BggIAZJu94fyEYDxDubRslATKYM/r10ncsEChMW29voq9aTiy0mCk QpiQCtvWZ64776di1Ewair793yWx594f9jBOzViTawl+5HgUoZy44lhcxz9Ka9xaM6Kv 9/4i5gsCQ0tYmGvIJ+JLD+Ouy+XafOhIsIwc5ssQJ6fydusmHSGU4N9gJT8DPAmUNgP0 L+RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=afE7Vxr8qLdVdkTUy6lxZoRfRPFBIqJx7vvUGWXU1Bg=; b=kVgJPCQdY9fgUciu5rKwvujpKfL4PjVGkudD4t3S6tic1YYE+Cx71EbOC8XRVi4M01 qXWHxKh2VnOb5bmMdxlGtW7ipnmJDDKmL49qcr3YaWSRHkN1NR0E8cv9c4J8aVtcxE40 EeJY8aS2bbYHyGcCI1JLZ4wqVRv3a80B6TyMF9CPJR1UxLQVeHXfHmQhLl0VKElRh/fq Jckp5DzPXoof+eSvSTUQGL0OUu251baJimY8/fmALcBOvmuhh8oXjR1mp7fMd1yeRHl9 mTeYoLqVYporSoKNeIji0YOEDOwx6XibLkj2FIWMF6kmT/Rggc2AfQYoYwUQJfCRP0Th a7/g== X-Gm-Message-State: AOAM530C+lbXtwM1zwOfjHK96mf9pFAJerk2vlmB9AijslxCUxKlk/B8 k85ARe2an53LT8cf0XoM44XR5YtCbvIM318OuOw= X-Google-Smtp-Source: ABdhPJz6DSHkJcjfi7i3bz1QsI4w6PtLCgwy20eDAjz1RqR6Uy6YZ4SrwJpXpTrX6wROlWSg9TmRLYCI5JvVN3rLm5s= X-Received: by 2002:a17:902:854c:b0:159:a70:deca with SMTP id d12-20020a170902854c00b001590a70decamr49572956plo.142.1653762478360; Sat, 28 May 2022 11:27:58 -0700 (PDT) In-Reply-To: <83k0ab5fqz.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:233272 Archived-At: --00000000000010cd4205e0169528 Content-Type: text/plain; charset="UTF-8" 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 wrote: > > Cc: 55599@debbugs.gnu.org > > From: Peter Ludemann > > 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. > --00000000000010cd4205e0169528 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems that there is a way = to get an interactive message to the terminal in batch mode ...

<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif">=C2=A0= =C2=A0 During daemon startup (with an existing .emacs.desktop file), I get= this on my terminal:

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

This seems to be from=C2=A0make-progress-rep= orter, which (if I read the code correctly) ends up calling=C2=A0(message &= quot;%s %s %s" text pulse-char suffix)). And that message displays int= eractively on the terminal.

So, there is a way to have the messages fr= om emacsclient --eval display on the terminal, but in some (most?) situatio= ns they don't. (The definition for message says: "In batch mode, the message is printe= d to the standard error stream,=C2=A0<= /span>followed by a = newline.") So, I infer that yes-o= r-no-p should just use "message" and all will be fine. (Another e= xample of a prompt that should go to the terminal but doesn't:= =C2=A0"Active processes exist; kill them and exit anyway" should = use "message".)

As to your suggested=C2=A0feature 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, th= e 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@debb= ugs.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 conditiona= lly 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&= #39;s too much trouble to fix) -- it seems that
> when "emacsclient -e" is used, any prompts go to the non-exi= stent 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<= br> interact with the user.=C2=A0 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.=C2=A0 So I'm unsure what issues are being discussed her= e
(but see below).

> Also, save-buffers-kill-emacs does two things: (conditionally) saves t= he buffers and deletes the
> ~/.emacs.d/.emacs.desktop.lock file. On the other hand, the lower leve= l 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.=C2=A0 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 o= f
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.=C2=A0 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.
--00000000000010cd4205e0169528--