From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: 24.4.50; obsolete messages hides warning on startup Resent-From: Robert Marshall Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Apr 2014 20:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 17272@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.139759457418774 (code B ref -1); Tue, 15 Apr 2014 20:43:01 +0000 Received: (at submit) by debbugs.gnu.org; 15 Apr 2014 20:42:54 +0000 Received: from localhost ([127.0.0.1]:49183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WaABx-0004sk-MK for submit@debbugs.gnu.org; Tue, 15 Apr 2014 16:42:54 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39657) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WaABu-0004sV-HO for submit@debbugs.gnu.org; Tue, 15 Apr 2014 16:42:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WaABh-0007M8-Vg for submit@debbugs.gnu.org; Tue, 15 Apr 2014 16:42:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WaABh-0007M3-Se for submit@debbugs.gnu.org; Tue, 15 Apr 2014 16:42:37 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WaABb-0007pv-Jk for bug-gnu-emacs@gnu.org; Tue, 15 Apr 2014 16:42:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WaABV-0007Jq-7t for bug-gnu-emacs@gnu.org; Tue, 15 Apr 2014 16:42:31 -0400 Received: from know-smtprelay-omc-7.server.virginmedia.net ([80.0.253.71]:40637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WaABU-0007IE-Vb for bug-gnu-emacs@gnu.org; Tue, 15 Apr 2014 16:42:25 -0400 Received: from capuchin.co.uk ([86.1.25.150]) by know-smtprelay-7-imp with bizsmtp id qLiL1n0723EJRsN01LiL3o; Tue, 15 Apr 2014 21:42:20 +0100 X-Originating-IP: [86.1.25.150] X-Spam: 0 X-Authority: v=2.1 cv=f8XGBYCM c=1 sm=1 tr=0 a=M7xYXag64YmbaeErs/qbeg==:117 a=M7xYXag64YmbaeErs/qbeg==:17 a=oWwmHH8kAAAA:8 a=MlfmOBwmbJwA:10 a=aGljky2k91gA:10 a=kj9zAlcOel0A:10 a=aR16PxjQAAAA:8 a=3E_tuTj2lir_A9SSs34A:9 a=CjuIK1q_8ugA:10 a=CiSHi91Bn78A:10 Received: from poulenc.faure (unknown [192.168.0.13]) by capuchin.co.uk (Postfix) with ESMTPS id 804A1DCA9 for ; Tue, 15 Apr 2014 21:42:20 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21325.39352.164247.185693@capuchin.co.uk> Date: Tue, 15 Apr 2014 21:42:32 +0100 From: Robert Marshall X-Mailer: VM 8.2.0b under 24.4.50.4 (i686-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) If you start emacs with the following loaded file (emacs -Q -l .emacs.test) ;;; .emacs.test (require 'longlines) (desktop-save-mode 1) (desktop-read "/home/robert") ;; $HOME.... When it starts you see the message Package longlines is obsolete! But - if the .emacs.desktop is locked the message: Warning: desktop file appears to be in use by PID 6464. Using it may cause conflicts. Use it anyway? (y or n) is hiding 'behind' the obsolete message and you don't see it until you press a key - the emacs startup appears to have stopped but there's no visual clue as to what it is waiting for. In GNU Emacs 24.4.50.4 (i686-pc-linux-gnu, GTK+ Version 3.8.6) of 2014-04-09 on poulenc Repository revision: 116959 dancol@dancol.org-20140409081641-wcask11smm10bk3f Windowing system distributor `The X.Org Foundation', version 11.0.11405000 System Description: Ubuntu 13.10 Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB Important settings: value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8-unix Robert -- Robert Marshall From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 21 05:45:49 2019 Received: (at control) by debbugs.gnu.org; 21 Sep 2019 09:45:50 +0000 Received: from localhost ([127.0.0.1]:59168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iBbxd-00067D-Ix for submit@debbugs.gnu.org; Sat, 21 Sep 2019 05:45:49 -0400 Received: from mail-pg1-f171.google.com ([209.85.215.171]:39722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iBbxZ-0005x6-42 for control@debbugs.gnu.org; Sat, 21 Sep 2019 05:45:47 -0400 Received: by mail-pg1-f171.google.com with SMTP id u17so5244756pgi.6 for ; Sat, 21 Sep 2019 02:45:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WNebZEo9EQSLB/o98BX5/Oo4V0cxtMrnEBtCP1D7aTY=; b=NVsZMGBU3fkvppcjpnqGNwfK1VwqFF1pteriPJ6WRZRtVzl/e0Od4gHAf6zxLqgKQu ca6kEP6DTaSw8a5EfiDkShzEmBrONoz6U2fct1MrRJ9mXYiw8ElgEstVjc/U0EO55kk2 2rqY2fKkICiLZRcwUujbKFe0guV05Ch0DN6zhF+iuVvDwYaiJy3Dze6Kl+tqAWlcVjEe QCs0nsWs6eLtXKURnPQ4JeHZNFC1MDuCdEuNDULyrGFUIa1FAWWOjisbNGmCDthgAsM7 5UiA/VxpF+a8g4thQ08p9lIMEiaJZhpz6FkLuIfr5X3nv7MeFdO4f8jwkprqfEluaMfU 1M3A== X-Gm-Message-State: APjAAAULpmZctw7Y25O50I2C124lzu9brQ2xvIGN2hVE1FseuBerivGj hdNjBpwjnw2jD6xPWLmgys5qlD24o3lVLpetb3pJevM9 X-Google-Smtp-Source: APXvYqwRz4lNPn1V3B5cuHlC7gMYfb+5poy+r1D77jnuyTtw/tXAEMT4Johh/0p2z6zVWsFUtQUysHEtiREzn8cuooM= X-Received: by 2002:a17:90a:cc08:: with SMTP id b8mr9494040pju.119.1569059139019; Sat, 21 Sep 2019 02:45:39 -0700 (PDT) MIME-Version: 1.0 From: Stefan Kangas Date: Sat, 21 Sep 2019 11:45:28 +0200 Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 2.4 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: merge 17272 19064 quit Content analysis details: (2.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.215.171 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.215.171 listed in wl.mailspike.net] 2.0 BLANK_SUBJECT Subject is present but empty 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.4 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: merge 17272 19064 quit Content analysis details: (1.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.215.171 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.215.171 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 2.0 BLANK_SUBJECT Subject is present but empty -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different merge 17272 19064 quit From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Oct 2019 17:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Michael Heerdegen Cc: 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157047009210072 (code B ref 17272); Mon, 07 Oct 2019 17:42:02 +0000 Received: (at 17272) by debbugs.gnu.org; 7 Oct 2019 17:41:32 +0000 Received: from localhost ([127.0.0.1]:49050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iHX0m-0002cJ-1S for submit@debbugs.gnu.org; Mon, 07 Oct 2019 13:41:32 -0400 Received: from quimby.gnus.org ([80.91.231.51]:42748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iHX0j-0002c3-04; Mon, 07 Oct 2019 13:41:30 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iHX0d-0006Vx-7g; Mon, 07 Oct 2019 19:41:27 +0200 From: Lars Ingebrigtsen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> Date: Mon, 07 Oct 2019 19:41:22 +0200 In-Reply-To: <87y4chjdop.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 26 Dec 2015 18:57:10 +0100") Message-ID: <87o8ys3131.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > Michael Heerdegen writes: > >> I tried this here with emacs 25: >> >> (progn >> (man "X") >> (y-or-n-p "-->")) >> >> This stills behave as described: the prompt disappears [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: > Michael Heerdegen writes: > >> I tried this here with emacs 25: >> >> (progn >> (man "X") >> (y-or-n-p "-->")) >> >> This stills behave as described: the prompt disappears and doesn't come >> back from alone. > > Yup; I get the same behaviour. That is indeed annoying, and should be > fixed. The issue is, I think, a general one: If some async code issues a `message', then that will hide the `y-or-n' prompt (or probably any prompt?). I don't think it's that difficult to check for this situation (`read-char' etc sets a flag that `message' checks? There's probably a mechanism in place for detecting this situation somewhere already), but what should Emacs do? I guess... one possibility would be to open the echo area further and show the message below the prompt. (Or above.) It is a general problem that I've been hit by a large number of times. If it's `y-or-n', then you can get out of it by hitting something other than y or n, but in other prompts you're basically helpless and have to `C-g' out of it. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Oct 2019 09:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15705261369257 (code B ref 17272); Tue, 08 Oct 2019 09:16:02 +0000 Received: (at 17272) by debbugs.gnu.org; 8 Oct 2019 09:15:36 +0000 Received: from localhost ([127.0.0.1]:49538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iHlag-0002PC-0M for submit@debbugs.gnu.org; Tue, 08 Oct 2019 05:15:34 -0400 Received: from mout.web.de ([212.227.17.12]:42317) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iHlad-0002Oq-Ii; Tue, 08 Oct 2019 05:15:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1570526118; bh=F6jJ/QXhT2IUvDbbNUonmzHKg6zTLEGxUC0I4pFL8Pc=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=B1ByzILGu7uulZetPGik42j1FzO6+uXnPAOQjlGV71ZgDDh0fRUewnGmrWSWpK4Y1 7Kj5bSb2C6oveRnp9vZLXbWkc6FUoFdmv7YZvJFSp52vV0f+qidQ5VY1jZfl3grOnI dYfGk1II+mNPME3+ehnK/k3eL27B2aa2QOMktTh4= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([94.218.185.16]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0Ls91n-1i6bYA3M2p-013vrL; Tue, 08 Oct 2019 11:15:17 +0200 From: Michael Heerdegen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> Date: Tue, 08 Oct 2019 11:15:23 +0200 In-Reply-To: <87o8ys3131.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 07 Oct 2019 19:41:22 +0200") Message-ID: <87h84jzjh0.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:hquay0mzVfNLY8VDUDtWbfez9GwKReYAjmm4cyAQkdDOggtlyO/ nMnvNe66zVcTSIVbUTyayf4mmIukleY+TMiBegDFeG6ovpY0CRLD2UcnCNZKJxrd3hmTaGz lzBRFj8oEaxVFMwxgnSSadVjnmZg8JDsC4zdsy2ZEPfcSsgf0DzIyP6Yt3ANRRF/YCsDOI5 5Y26rwqU6oTBNjWnYQ3WA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:qzzfcBvqVWI=:09oxptl+NUuvoroWmYu2Jr gPpl+/+xnxn/950m/UiD7Y2FGlPaM8deGarX71Bj2ruxSFCBUFvb1Bvck7qLh/GvJsvUAqcUQ TACJM8Mu1DkUdBPEe15OdAxHskP2fvwbbSp0DWmiWsiablsILxwvT30OEutREnguAURj2JefG wTU1Ndgid7ScjIF8+P52FY9XVXITAMUnJLH0bFMMw0FLW6kfLPCwZWNJ83Q6HOzq5E+7uVWao zhdSvy6aiybeSP1wHxTDFrn5J9TwmlmRJUPaaGArxuZGBQ5EPu6yjxtGHroqA/CSIlDd2Gbk1 72mywNPYrmnZaVPChVA/6GxzSDUXt1aS2jGu0Xej7q5OImBGSJQX24FsY7PAMQZ+ZqEOr8AMH 1SXX+rURBU3ulnz89aUD1693zbCwkrtOTiKXdplsG/gS2zO7YGzQm20Fbt2JJAuTHreXJAMuU 9cWQzcjiekJVvJZFan++xD4TpEWl5sk7mzCp+MZbPMwCJbpNL7M9FNs4GNbq48HVuuGvIq8g+ OC0FS4prr2V+23DXs+ryc2Z+HrLfFnU08vKPzWOK8jXnmv3ozY8pu68Tr9PaOgHiWLDkrQWXf FglGA7Pn1DFamXgFKyJ6+rcNNoTfTS4fwyRRpdBTNYUYploWWPKAd/4eqcCvdFO0BPb6l70Pd 3SBtpSfXssge/lri1hi5SkyA9KvIlhOX5LmMxAwvdiTqeK383mEps638FFJX3CRvpj8CEUROJ qB1Zqr2068SJ0atSa9ogXUHsWWI/XxPYmL8Gtdq072GEOGuIFFGtumP0vRhMRAOzVV1nM8jYh lFo7I4Pu6p4pgwVkEXSptUPYjjdKuBQpp/MVw/gdIbXNDu8+KaaoIgu87fKkC9Rl7U6bTv/0P 7iuIiHTx3ggf/yuxR+f1W5C/Az20p41YNXO85U4fxaGVzzrpSVDMOk1W2ztI5WOOmzrXcx7n9 fuBfh5WVjCkbqoPCknyiBWBgPNU4XGjkq6HNqsykBmgm7Xsy02lOlUeOfMODlv9KYkKZfzCrL E8dnIOtXH/t+9SCU6tV2BmGZaxEIksiNoLMsOEJ888VGEUlwpLCfhjGdr2Uzxau7xqzMU3kL7 uD5puKkIjFBK4oHDZDfS6gYBqK+wpq1xREpMjCmMkZMnTG//VLLjpxEw4VBvDYxfhNRszcvbQ /2Ud4fyD8BVxa/bWVrJi5rxbnt3dU18K4rqiPviupFtY0veW2ZiUvC8nP+LWKwJ0X0COZb7cv VJ+lkOk9ICjbGxXoAIhq7ma9h4cJTuW2v8Vka5gtiORFjnllo0NbnO9JN/5c= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: > >> (progn > >> (man "X") > >> (y-or-n-p "-->")) > >> > >> the prompt disappears and doesn't come back from alone. > but what should Emacs do? > > I guess... one possibility would be to open the echo area further and > show the message below the prompt. (Or above.) Yeah. Or alternatively, y-or-n-p could check for this situation and restore the prompt after a certain delay (2 or 3 seconds or so). Regards, Michael. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Oct 2019 15:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Michael Heerdegen Cc: 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157054949013455 (code B ref 17272); Tue, 08 Oct 2019 15:45:02 +0000 Received: (at 17272) by debbugs.gnu.org; 8 Oct 2019 15:44:50 +0000 Received: from localhost ([127.0.0.1]:51254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iHrfN-0003Us-NR for submit@debbugs.gnu.org; Tue, 08 Oct 2019 11:44:50 -0400 Received: from quimby.gnus.org ([80.91.231.51]:38406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iHrfL-0003Ud-5u; Tue, 08 Oct 2019 11:44:47 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iHrfF-0006ov-Ku; Tue, 08 Oct 2019 17:44:44 +0200 From: Lars Ingebrigtsen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <87h84jzjh0.fsf@web.de> Date: Tue, 08 Oct 2019 17:44:41 +0200 In-Reply-To: <87h84jzjh0.fsf@web.de> (Michael Heerdegen's message of "Tue, 08 Oct 2019 11:15:23 +0200") Message-ID: <875zkz2qdy.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Heerdegen writes: > Yeah. Or alternatively, y-or-n-p could check for this situation and > restore the prompt after a certain delay (2 or 3 seconds or so). Yeah, that would feel quite natural, I think. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Heerdegen writes: > Yeah. Or alternatively, y-or-n-p could check for this situation and > restore the prompt after a certain delay (2 or 3 seconds or so). Yeah, that would feel quite natural, I think. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 13 14:34:24 2019 Received: (at control) by debbugs.gnu.org; 13 Oct 2019 18:34:24 +0000 Received: from localhost ([127.0.0.1]:36932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iJihE-0004on-6a for submit@debbugs.gnu.org; Sun, 13 Oct 2019 14:34:24 -0400 Received: from quimby.gnus.org ([80.91.231.51]:35960) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iJihB-0004oe-Vz for control@debbugs.gnu.org; Sun, 13 Oct 2019 14:34:22 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iJih8-0003yI-GW for control@debbugs.gnu.org; Sun, 13 Oct 2019 20:34:20 +0200 Date: Sun, 13 Oct 2019 20:34:18 +0200 Message-Id: <87k198a40l.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #446 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: forcemerge 446 19064 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) forcemerge 446 19064 quit From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Nov 2019 23:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157299549320656 (code B ref 17272); Tue, 05 Nov 2019 23:12:01 +0000 Received: (at 17272) by debbugs.gnu.org; 5 Nov 2019 23:11:33 +0000 Received: from localhost ([127.0.0.1]:39207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iS7z2-0005N4-MT for submit@debbugs.gnu.org; Tue, 05 Nov 2019 18:11:32 -0500 Received: from eastern.birch.relay.mailchannels.net ([23.83.209.55]:22912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iS7yz-0005Mo-Kd; Tue, 05 Nov 2019 18:11:31 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3E4771A0C6D; Tue, 5 Nov 2019 23:11:28 +0000 (UTC) Received: from pdx1-sub0-mail-a93.g.dreamhost.com (100-96-6-183.trex.outbound.svc.cluster.local [100.96.6.183]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BFD5A1A08FB; Tue, 5 Nov 2019 23:11:27 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a93.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 05 Nov 2019 23:11:28 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Tank-Tart: 5b50183e456fadae_1572995488043_526594295 X-MC-Loop-Signature: 1572995488043:2035839066 X-MC-Ingress-Time: 1572995488042 Received: from pdx1-sub0-mail-a93.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a93.g.dreamhost.com (Postfix) with ESMTP id EC19B7F54F; Tue, 5 Nov 2019 15:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=4ftfhdiG+XkGRzzcPEi0DbtK2K0=; b= CwK29/usd0JRa941Scg1Jt5whwmqW7gfFxx4gonr5JeHe7eGMOm5OTA2hd3FCf2b RFFP7seyRl2NtZ1ehf4nSWFVtSxxZubATMDeKdZQmHsWqf/XiqJzqUGz/ytT072w icR81ZN9MofcffJrnuwboPiBlcAWgh9Ds5uiJU1+BgI= Received: from mail.jurta.org (m91-129-101-77.cust.tele2.ee [91.129.101.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a93.g.dreamhost.com (Postfix) with ESMTPSA id F188E7F633; Tue, 5 Nov 2019 15:11:17 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a93 From: Juri Linkov References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> Date: Wed, 06 Nov 2019 01:10:49 +0200 In-Reply-To: <87o8ys3131.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 07 Oct 2019 19:41:22 +0200") Message-ID: <875zjx6hs6.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > It is a general problem that I've been hit by a large number of times. > If it's `y-or-n', then you can get out of it by hitting something other > than y or n, but in other prompts you're basically helpless and have to > `C-g' out of it. Message "Package cl is deprecated" that overwrites `y-or-n-p' prompt issued by desktop.el could be fixed by this patch (requires another patch from bug#38076): diff --git a/lisp/subr.el b/lisp/subr.el index 03cf3da278..0a8a505b70 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -4517,7 +4551,9 @@ do-after-load-evaluation (byte-compile-warn "%s" msg)) (run-with-timer 0 nil (lambda (msg) - (message "%s" msg)) + (if (minibufferp) + (minibuffer-message "%s" msg) + (message "%s" msg))) msg))))) ;; Finally, run any other hook. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: 24.4.50; obsolete messages hides warning on startup Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Nov 2019 22:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Robert Marshall Cc: 17272@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15730794891397 (code B ref 17272); Wed, 06 Nov 2019 22:32:01 +0000 Received: (at 17272) by debbugs.gnu.org; 6 Nov 2019 22:31:29 +0000 Received: from localhost ([127.0.0.1]:41364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iSTpp-0000MT-Hz for submit@debbugs.gnu.org; Wed, 06 Nov 2019 17:31:29 -0500 Received: from azure.elm.relay.mailchannels.net ([23.83.212.7]:43469) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iSTpn-0000MF-P2 for 17272@debbugs.gnu.org; Wed, 06 Nov 2019 17:31:28 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 754315E3559; Wed, 6 Nov 2019 22:31:26 +0000 (UTC) Received: from pdx1-sub0-mail-a79.g.dreamhost.com (100-96-18-10.trex.outbound.svc.cluster.local [100.96.18.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 09D725E3672; Wed, 6 Nov 2019 22:31:26 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a79.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Wed, 06 Nov 2019 22:31:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Slimy-Duck: 433b148471025c8c_1573079486284_1626963357 X-MC-Loop-Signature: 1573079486283:1233170200 X-MC-Ingress-Time: 1573079486283 Received: from pdx1-sub0-mail-a79.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a79.g.dreamhost.com (Postfix) with ESMTP id 7A80CA3358; Wed, 6 Nov 2019 14:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=dWEjT/SOu9hkGK5u9/gQg/4531I=; b= HzgUP93efRY5pxVq1SiICLGgeQr4KpP3zz3p6/BSUuP/Mf++t+ziI7yOVymUldWR NnZhGlRhAHdZGDqUj4QY2sOqnTT8/ORuXbYXvJTwdBmigX9ObKITq6TvtlsvnO+M uM3rkGPKRrbECizPeDnWPt7ZtpBxc6KAZDOMX7Moov8= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a79.g.dreamhost.com (Postfix) with ESMTPSA id 748A4A33BB; Wed, 6 Nov 2019 14:31:18 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a79 From: Juri Linkov References: <21325.39352.164247.185693@capuchin.co.uk> Date: Thu, 07 Nov 2019 00:22:04 +0200 In-Reply-To: <21325.39352.164247.185693@capuchin.co.uk> (Robert Marshall's message of "Tue, 15 Apr 2014 21:42:32 +0100") Message-ID: <87k18c7iib.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > If you start emacs with the following loaded file (emacs -Q -l .emacs.test) > > ;;; .emacs.test > (require 'longlines) > (desktop-save-mode 1) > (desktop-read "/home/robert") ;; $HOME.... > > When it starts you see the message > > Package longlines is obsolete! > > But - if the .emacs.desktop is locked the message: > > Warning: desktop file appears to be in use by PID 6464. > Using it may cause conflicts. Use it anyway? (y or n) > > is hiding 'behind' the obsolete message and you don't see it until you > press a key - the emacs startup appears to have stopped but there's no > visual clue as to what it is waiting for. Here is the patch that fixes this (required changes from bug#38076): diff --git a/lisp/subr.el b/lisp/subr.el index 03cf3da278..33464d6032 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -4517,7 +4556,9 @@ do-after-load-evaluation (byte-compile-warn "%s" msg)) (run-with-timer 0 nil (lambda (msg) - (message "%s" msg)) + (if (minibufferp) + (minibuffer-message "%s" msg) + (message "%s" msg))) msg))))) ;; Finally, run any other hook. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Nov 2019 20:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157324670110044 (code B ref 17272); Fri, 08 Nov 2019 20:59:02 +0000 Received: (at 17272) by debbugs.gnu.org; 8 Nov 2019 20:58:21 +0000 Received: from localhost ([127.0.0.1]:47739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTBKm-0002bq-TW for submit@debbugs.gnu.org; Fri, 08 Nov 2019 15:58:21 -0500 Received: from quimby.gnus.org ([80.91.231.51]:53366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTBKk-0002bc-3E; Fri, 08 Nov 2019 15:58:18 -0500 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iTBKf-0007Gx-T6; Fri, 08 Nov 2019 21:58:16 +0100 From: Lars Ingebrigtsen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> Date: Fri, 08 Nov 2019 21:58:13 +0100 In-Reply-To: <875zjx6hs6.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 06 Nov 2019 01:10:49 +0200") Message-ID: <87sgmy3x22.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > Message "Package cl is deprecated" that overwrites `y-or-n-p' prompt > issued by desktop.el could be fixed by this patch (requires another > patch from bug#38076): Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Juri Linkov writes: > Message "Package cl is deprecated" that overwrites `y-or-n-p' prompt > issued by desktop.el could be fixed by this patch (requires another > patch from bug#38076): [...] > - (message "%s" msg)) > + (if (minibufferp) > + (minibuffer-message "%s" msg) > + (message "%s" msg))) Wouldn't it make more sense to just have `message' behave like `minibuffer-message' if '(minibufferp)'? Otherwise all async code will have to have this code snippet. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Nov 2019 21:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen , Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157324795912367 (code B ref 17272); Fri, 08 Nov 2019 21:20:01 +0000 Received: (at 17272) by debbugs.gnu.org; 8 Nov 2019 21:19:19 +0000 Received: from localhost ([127.0.0.1]:47817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTBf4-0003DK-Kc for submit@debbugs.gnu.org; Fri, 08 Nov 2019 16:19:18 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:42608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTBf0-0003Cn-7i; Fri, 08 Nov 2019 16:19:14 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xA8L95Cl174922; Fri, 8 Nov 2019 21:19:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=dbMnIIKsLPt19PtTYXUUWaB6SajjADE76uiTGLUp8eQ=; b=MZ4OrKJYdpoKN0RocgDC9KEXbrAsj22yS3SiV6kbZl04wOqElQYEywmT4Agmrw30sLjd T3F0eYsl0Ff372GKFycImxl628cYDN4oYVR26ylTF0fPRkzqrTs+ZrPmjPV3Pl1m7Pqr NGYqEOanMI1vATPFnu4BxdnFFDPxnU5xbHAaTUs1+J6MnaWK6Y5Wev6MNL39EsOBy4xS uO5G7Vi9VsKajFlFvcuRcEa3FxqE75KyulMAoM2z9f+Pp5lQVsGR4b/fAWcJ2Ln+eswW Qn93NZb5qsub/Mki/EMilYKo1LndCK1PLd4mgsGLVJHXpKEBqs+/OeM7u/sn+Cvs6Ns+ JA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 2w41w17r0s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 21:19:07 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xA8L7nKg094616; Fri, 8 Nov 2019 21:19:07 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2w5cxkdv9m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 21:19:07 +0000 Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xA8LJ3rA012760; Fri, 8 Nov 2019 21:19:04 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 8 Nov 2019 13:19:02 -0800 (PST) From: Drew Adams References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> In-Reply-To: <87sgmy3x22.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9435 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=844 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911080204 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9435 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=920 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911080204 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > -=09=09=09 (message "%s" msg)) > > + (if (minibufferp) > > + (minibuffer-message "%s" msg) > > + (message "%s" msg))) >=20 > Wouldn't it make more sense to just have `message' behave like > `minibuffer-message' if '(minibufferp)'? Otherwise all async code will > have to have this code snippet. FWIW, I disagree very much with the patch - and with Lars's suggestion. Both `message' and `minibuffer-message' are useful when the minibuffer is active. They behave very differently, and each behavior is useful. `message' interrupts your minibuffer dialog temporarily (and how & how much can be controlled). And it logs to `*Messages*' (and that can be controlled). Use it when it's appropriate to do those things (particularly the interruption). `minibuffer-message' uses the same real estate, at the same time, as your minibuffer input. It is definitely NOT the case that it is always most useful for a message while the minibuffer is active to be delivered by just appending it to your input, and not interrupting the dialog. ___ The problem described by the bug report needs to be solved some other way. It has nothing to do, necessarily, with `minibuffer-message' versus `message'. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: 24.4.50; obsolete messages hides warning on startup Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Nov 2019 23:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Robert Marshall Cc: 17272@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15733408083802 (code B ref 17272); Sat, 09 Nov 2019 23:07:02 +0000 Received: (at 17272) by debbugs.gnu.org; 9 Nov 2019 23:06:48 +0000 Received: from localhost ([127.0.0.1]:50436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTZoe-0000zG-9j for submit@debbugs.gnu.org; Sat, 09 Nov 2019 18:06:48 -0500 Received: from brown.elm.relay.mailchannels.net ([23.83.212.23]:41531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTZoc-0000z7-LH for 17272@debbugs.gnu.org; Sat, 09 Nov 2019 18:06:47 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 18808141191; Sat, 9 Nov 2019 23:06:45 +0000 (UTC) Received: from pdx1-sub0-mail-a16.g.dreamhost.com (100-96-92-150.trex.outbound.svc.cluster.local [100.96.92.150]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A6BC514024B; Sat, 9 Nov 2019 23:06:44 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a16.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sat, 09 Nov 2019 23:06:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Thread-Occur: 075e9c71141e819c_1573340804896_2747952433 X-MC-Loop-Signature: 1573340804896:3987715180 X-MC-Ingress-Time: 1573340804895 Received: from pdx1-sub0-mail-a16.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a16.g.dreamhost.com (Postfix) with ESMTP id 2EDB6A3059; Sat, 9 Nov 2019 15:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=KnPgIbxW8JhofzIhyhnTZiwdEnc=; b= CsclkQMFw4QItVlvSQAHW2XKAOGvc3k6kAQNndZPjWF9eHdH5HLp+4hLAMYzBK43 BwCCWoW9UQVgcW9s93fUGdqf+1ENXLlf/t6h/Ifd/A9XUHuOQMP5GnFa6jlUuPtG T5NoRpgPgSi0qxzMt1cO+4Ne/yRg3hT6glz7iEXcBf0= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a16.g.dreamhost.com (Postfix) with ESMTPSA id E7492A0E8F; Sat, 9 Nov 2019 15:06:36 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a16 From: Juri Linkov References: <21325.39352.164247.185693@capuchin.co.uk> Date: Sun, 10 Nov 2019 00:46:55 +0200 In-Reply-To: <21325.39352.164247.185693@capuchin.co.uk> (Robert Marshall's message of "Tue, 15 Apr 2014 21:42:32 +0100") Message-ID: <87a794d5wg.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > If you start emacs with the following loaded file (emacs -Q -l .emacs.test) > > ;;; .emacs.test > (require 'longlines) > (desktop-save-mode 1) > (desktop-read "/home/robert") ;; $HOME.... > > When it starts you see the message > > Package longlines is obsolete! > > But - if the .emacs.desktop is locked the message: > > Warning: desktop file appears to be in use by PID 6464. > Using it may cause conflicts. Use it anyway? (y or n) > > is hiding 'behind' the obsolete message and you don't see it until you > press a key - the emacs startup appears to have stopped but there's no > visual clue as to what it is waiting for. This is fixed now. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Nov 2019 23:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15733408243880 (code B ref 17272); Sat, 09 Nov 2019 23:08:02 +0000 Received: (at 17272) by debbugs.gnu.org; 9 Nov 2019 23:07:04 +0000 Received: from localhost ([127.0.0.1]:50444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTZou-00010V-2r for submit@debbugs.gnu.org; Sat, 09 Nov 2019 18:07:04 -0500 Received: from bird.elm.relay.mailchannels.net ([23.83.212.17]:56411) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTZos-0000zo-1i; Sat, 09 Nov 2019 18:07:02 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A017C140DB7; Sat, 9 Nov 2019 23:07:00 +0000 (UTC) Received: from pdx1-sub0-mail-a16.g.dreamhost.com (100-96-18-10.trex.outbound.svc.cluster.local [100.96.18.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 25834140591; Sat, 9 Nov 2019 23:07:00 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a16.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sat, 09 Nov 2019 23:07:00 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Tank-Exultant: 14f2201c26cda305_1573340820413_423954516 X-MC-Loop-Signature: 1573340820412:748470665 X-MC-Ingress-Time: 1573340820412 Received: from pdx1-sub0-mail-a16.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a16.g.dreamhost.com (Postfix) with ESMTP id 2DF8FA3059; Sat, 9 Nov 2019 15:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=cdG1PiVKNkuQFXEwwuLhxK4e6IQ=; b= wMBbMIu88sB9mtzBzTYHzGpcdgY/MrESEpOGLSE0CwkGC3uJHXq2BotuBXHYWbea n1aJN5GNXL+FCwnXSDxFdBG0RG7xUODs9TGJZhW3PvVMj6ZwwjXXyyfjcj4yMix1 OBrbvGd1kmEHXGr9XMQzbgoA7W8y+s831fNMNEcoq8c= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 7DB07A3053; Sat, 9 Nov 2019 15:06:51 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a16 From: Juri Linkov References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> Date: Sun, 10 Nov 2019 01:01:57 +0200 In-Reply-To: <87sgmy3x22.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 08 Nov 2019 21:58:13 +0100") Message-ID: <871rugbqmy.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> - (message "%s" msg)) >> + (if (minibufferp) >> + (minibuffer-message "%s" msg) >> + (message "%s" msg))) > > Wouldn't it make more sense to just have `message' behave like > `minibuffer-message' if '(minibufferp)'? Otherwise all async code will > have to have this code snippet. I agree, this would make code more manageable. But a question: after reversing the dependency should it be customizable to get back an old behavior for Drew? From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2019 02:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157352483230848 (code B ref 17272); Tue, 12 Nov 2019 02:14:02 +0000 Received: (at 17272) by debbugs.gnu.org; 12 Nov 2019 02:13:52 +0000 Received: from localhost ([127.0.0.1]:56203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iULgm-00081S-7B for submit@debbugs.gnu.org; Mon, 11 Nov 2019 21:13:52 -0500 Received: from quimby.gnus.org ([95.216.78.240]:41416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iULgh-000812-K9; Mon, 11 Nov 2019 21:13:48 -0500 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iULgX-0000iO-NP; Tue, 12 Nov 2019 03:13:40 +0100 From: Lars Ingebrigtsen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> Date: Tue, 12 Nov 2019 03:13:36 +0100 In-Reply-To: <871rugbqmy.fsf@mail.linkov.net> (Juri Linkov's message of "Sun, 10 Nov 2019 01:01:57 +0200") Message-ID: <87d0dxyh7z.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > But a question: after reversing the dependency should it be > customizable to get back an old behavior for Drew? I didn't quite understand what Drew wanted (to have the prompt be overwritten?), but if so, a user option would be trivial to add, wouldn't it? Like `display-messages-in-minibuffer' or something? Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ingebrigtsen.no] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Juri Linkov writes: > But a question: after reversing the dependency should it be > customizable to get back an old behavior for Drew? I didn't quite understand what Drew wanted (to have the prompt be overwritten?), but if so, a user option would be trivial to add, wouldn't it? Like `display-messages-in-minibuffer' or something? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2019 15:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen , Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15735729039430 (code B ref 17272); Tue, 12 Nov 2019 15:36:01 +0000 Received: (at 17272) by debbugs.gnu.org; 12 Nov 2019 15:35:03 +0000 Received: from localhost ([127.0.0.1]:58201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUYC6-0002Rw-Q2 for submit@debbugs.gnu.org; Tue, 12 Nov 2019 10:35:03 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:58872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUYC3-0002RK-69; Tue, 12 Nov 2019 10:35:00 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xACFOjlB071273; Tue, 12 Nov 2019 15:34:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=oS0/8YUg+GFHF0Eh5Tg+zT1y2R4DS77yi7w7Iti6Jsw=; b=TSlD+Adr+bJSwRact68V/8pjsi/4qgN+TtbrpJ0vZAe4qSpCeNlnc7AAvUeDZ2MmeUni B46d04VLSn5Eb0jTEyFjl/YpBQZ3O8qqFY3GZSJq/uzLNsMF6SAoxK8o7fWqK/3VXLfV DmjuqeQ9e85Eyd1yUu6tz5WJNLcXuc+fuxB4LelJRD/vR5IXkSiMO/Q6en5mvmUPDl61 s1/20tcuJ7R17FZwG2UXKa1vJj+VBGgM/WZ+DLGVjlWaJnviwDkgAzxwlGcIHsEtVAzM UA+BFo1mGx44c6owzwOvUHMzgEdfPSwZ5Hk5ydRekuIWu0vwnd5JCyvmRK2ank84doM7 Qg== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2w5p3qnhef-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Nov 2019 15:34:52 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xACFOTE4102396; Tue, 12 Nov 2019 15:34:51 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 2w7vpmfjb9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Nov 2019 15:34:51 +0000 Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xACFYkso032146; Tue, 12 Nov 2019 15:34:49 GMT MIME-Version: 1.0 Message-ID: <53c55db5-d623-4946-af2e-d141e7bc7acd@default> Date: Tue, 12 Nov 2019 15:34:45 +0000 (UTC) From: Drew Adams References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> In-Reply-To: <87d0dxyh7z.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9438 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911120134 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9438 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911120134 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > But a question: after reversing the dependency should it be > > customizable to get back an old behavior for Drew? >=20 > I didn't quite understand what Drew wanted (to have the prompt be > overwritten?), but if so, a user option would be trivial to add, > wouldn't it? Like `display-messages-in-minibuffer' or something? I'm sorry, but I can't follow this. I don't know what's been changed, or why. (There are even two bugs that are being handled here, apparently.) What I've said is that I object to an automatic attempt to determine, when the minibuffer is active, whether to realize the effect of `message' or the effect of `minibuffer-message'. The minibuffer can be active - or not - during any number of other activities. The minibuffer is for user input, but that space is also (as the echo area) for `message' output. And such output - messages to the user - can, and should be able to, be delivered while a user is using the minibuffer for input. Nothing wrong with that, in general. `message' is often, and can always be, associated with an _interruption_: `sit-for' or `sleep-for'. This is part of a normal UI dialog/interaction - one kind of such interaction. This applies also when you're using the minibuffer. It can make sense to interrupt inputting briefly, to deliver a message. `message', unlike `minibuffer-message', not only interrupts input (switching to the echo area). By doing so it also takes over that complete space. Yes, that hides your input temporarily - but that's the point. The complete space is available for a message. It's saying, "Forget about your inputting for a moment, and read this important announcement." (`message' also logs messages, which can be very important.) `minibuffer-message' is limited to appending to your minibuffer input. Much less space available. And no interruption, no real separation from your input (apart from the brackets). Minibuffer input can be long and complex, even using multiple lines. `message' allows complete separation of the input space from the output space. But yes, it separates in time, not space. Is that bad? good? It depends. Consider also recursive minibuffers. Imagine, in fact, that the minibuffer is _always_ active. You can continue to use Emacs normally in this scenario. `message' needs to work normally, as does `minibuffer-message', regardless of whether the minibuffer is active. In sum, BOTH `message' and `minibuffer-message' have their uses when the minibuffer is active. They are _different_. Neither is good or bad. It is absolutely wrong - misguided - to suppose that when the minibuffer is active all messages should be delivered using `minibuffer-message'. It's up to the functions that _use_ these two output functions to DTRT. Consider an asynchronous process trying to deliver progress or result messages. Should it use the echo area? If so, maybe `message' with a hard interruption (`sleep-for') is appropriate. Or maybe it's appropriate to pop up a buffer to show the messages. Or maybe it's appropriate to use `message' if the minibuffer is active or `minibuffer-message' if not. It all depends. There are lots of UI and reporting possibilities. It's up to the functions that are trying to tell the user something to decide and do what's appropriate. It's not up to the minibuffer ("Am I active?") to decide. No simple rule/condition (e.g. minibuffer is active) can reasonably determine which output effect should be used in a particular situation. This BUG is about a particular scenario where the functions that use output functions interact badly during minibuffer input. That's a PARTICULAR scenario. A proper fix for the bug is to find a solution specific to that scenario - to coordinate or otherwise referee among the participants that vie for the user's attention. Not taking account of the particular scenario is wrong (and perhaps a cop-out). Determine the real, problematic scenario, and provide a remedy for that. Don't try to elevate this to some general, abstract, blanket, one-size-fits-all, hard-coded rule to finesse messages during minibuffer input. Analyze the real, specific problem in the reported scenario, and provide a solution for that. Don't overreach. Don't paint everything the same color just because there's a scenario where the color scheme is problematic. That's my point. Please do _not_ impose `minibuffer-message' as a replacement for `message' when the minibuffer is active. Don't stop _callers_ from determining the appropriate behavior. If a caller uses `message' then respect that. If the caller does something stupid then fix the caller. I said (perhaps in this thread) that I have a function, `icicle-msg-maybe-in-minibuffer', that does this - something similar to what I guess you have in mind imposing in some systematic way: (icicle-msg-maybe-in-minibuffer FORMAT-STRING &rest ARGS) Display FORMAT-STRING as a message. If called with the minibuffer inactive, use 'message'. Otherwise: If 'icicle-minibuffer-message-ok-p', then use 'minibuffer-message'. Else do nothing (no message display). But the point is that that's just another output function, available for use by callers. I don't just impose that systematically. For some callers, using that instead of `message', or instead of `minibuffer-message', makes sense. For others it makes sense to just use `message' or `minibuffer-message'. (And you'll notice that I even provide a global variable, `icicle-minibuffer-message-ok-p', that can be bound to override substituting `minibuffer-message' for `message'.) I don't object to ever using `minibuffer-message' in place of `message'. I object to doing that systematically. I object to doing that behind the backs of callers - let the callers decide. Can odd or unpleasant behavior sometimes result, due to caller behavior conflicts? Of course. That's rare, IME, but it can happen. When it does. it needs to be fixed - for that particular scenario. And in particular, if there's something very important that a caller is doing - some very important message communication, then probably something other than `message' and other than `minibuffer-message' is appropriate - e.g., a popup, maybe even a modal, dialog. Dunno whether this long reply makes clear "what Drew wanted". I hope it helps. And I hope you'll reconsider the simplistic "solution" that I think you've planned. If I'm mistaken wrt the planned solution, apologies. At least I hope I've made clear my objection to what I've thought the plan is. Thanks for listening. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2019 22:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Drew Adams Cc: Michael Heerdegen , Lars Ingebrigtsen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157359725130585 (code B ref 17272); Tue, 12 Nov 2019 22:21:01 +0000 Received: (at 17272) by debbugs.gnu.org; 12 Nov 2019 22:20:51 +0000 Received: from localhost ([127.0.0.1]:58553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUeWp-0007xE-B5 for submit@debbugs.gnu.org; Tue, 12 Nov 2019 17:20:51 -0500 Received: from black.elm.relay.mailchannels.net ([23.83.212.19]:19697) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUeWn-0007x2-8w; Tue, 12 Nov 2019 17:20:50 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DCD0F212B6; Tue, 12 Nov 2019 22:20:47 +0000 (UTC) Received: from pdx1-sub0-mail-a63.g.dreamhost.com (100-96-6-183.trex.outbound.svc.cluster.local [100.96.6.183]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6E606215A9; Tue, 12 Nov 2019 22:20:47 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a63.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 12 Nov 2019 22:20:47 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Stretch-Hook: 16603b257be0682f_1573597247692_3134534366 X-MC-Loop-Signature: 1573597247691:3597698131 X-MC-Ingress-Time: 1573597247691 Received: from pdx1-sub0-mail-a63.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a63.g.dreamhost.com (Postfix) with ESMTP id 1BDF783340; Tue, 12 Nov 2019 14:20:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=AQ/oPgYTdsY097KWUX/9UNLuHNw=; b= T1s1Ne+b8Zf7+kU8OTOBvLw3xMNlBX0Y6aUl5iuCaBc2migqWx4RefMzk3LjSfO1 +nkq5uTBHn7rY0NO9C93QcFAK+M4HQn73EKwbgWehZcPBVOSMvwKmztPwRHYORMG lHVO6Fal5RuVz1OjqVl4e0LW2WqFIT1u2I5swRS/hL8= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a63.g.dreamhost.com (Postfix) with ESMTPSA id C2FEA8333E; Tue, 12 Nov 2019 14:20:38 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a63 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> Date: Wed, 13 Nov 2019 00:20:03 +0200 In-Reply-To: <53c55db5-d623-4946-af2e-d141e7bc7acd@default> (Drew Adams's message of "Tue, 12 Nov 2019 15:34:45 +0000 (UTC)") Message-ID: <87tv78g2jw.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > `message', unlike `minibuffer-message', not only > interrupts input (switching to the echo area). > By doing so it also takes over that complete space. > > Yes, that hides your input temporarily - but that's > the point. No, `message' hides your input not temporarily, but permanently. That's the problem. And `minibuffer-message' fixes it both ways: when the minibuffer is active, it displays the message at the end of the minibuffer for 2 seconds. When the minibuffer is not active, it displays the message in the echo area for 2 seconds (the timeout is configurable). > (`message' also logs messages, which can be very > important.) `minibuffer-message' logs messages as well. > Don't stop _callers_ from determining the > appropriate behavior. If a caller uses > `message' then respect that. If the caller > does something stupid then fix the caller. Callers will be able to determine the appropriate behavior using new variable like `display-messages-in-minibuffer'. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2019 23:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , Lars Ingebrigtsen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15736010663892 (code B ref 17272); Tue, 12 Nov 2019 23:25:01 +0000 Received: (at 17272) by debbugs.gnu.org; 12 Nov 2019 23:24:26 +0000 Received: from localhost ([127.0.0.1]:58615 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUfWM-00010c-Cw for submit@debbugs.gnu.org; Tue, 12 Nov 2019 18:24:26 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:41198) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUfWK-00010J-9u; Tue, 12 Nov 2019 18:24:24 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xACNOHrm119241; Tue, 12 Nov 2019 23:24:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=NC4hfEWS2+crqB69S4ob9OYbhmTnBW2Upj5QKKDeFXA=; b=E0IpGFU/KWwqAKCR5eOkWGnpgmy9ihQ0EQWE+6K3UIpOBDWEv4MJDpbIa9uWEqp4KfLJ Gut19scChIZCA2riaVgpMeUW+XrF+wHefm/5Ws+brLbsDghJFgX+d4OYzahfEf5iPdPm ZKJwYaxk0/mUteSN7e8xrQh8Zz0SbmTEgmVEkr1vY7hFitL0fhB3HjcXNpQCWV7UmluN ka+VQ6PX8OewwmLb+GT+LZwzeNbL9CoF444uclU/rkH7zP5wjCTZ+/Gxk1nY/AC6kk7Q lQOr0sQSAzoR1EFSxyhWFM+3LtV8AsgWE2rKtFgGQuwgioVL8cjR+v17FxdSqekfQT4h bg== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 2w5ndq88c9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Nov 2019 23:24:17 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xACNODX0085862; Tue, 12 Nov 2019 23:24:16 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 2w7vbbrg4v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Nov 2019 23:24:15 +0000 Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xACNN58R014400; Tue, 12 Nov 2019 23:23:09 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 12 Nov 2019 15:23:04 -0800 (PST) From: Drew Adams References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87tv78g2jw.fsf@mail.linkov.net> In-Reply-To: <87tv78g2jw.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9439 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=2 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=2 mlxscore=2 mlxlogscore=163 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911120200 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9439 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=233 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911120200 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > `message', unlike `minibuffer-message', not only > > interrupts input (switching to the echo area). > > By doing so it also takes over that complete space. > > > > Yes, that hides your input temporarily - but that's > > the point. >=20 > No, `message' hides your input not temporarily, > but permanently. That's the problem. How so, _permanently_? That's not what I see, ever. Permanent hiding means your input is lost, destroyed/irretrievable - impossible to show again. I've never seen `message' - or any other use of the echo area, destroy minibuffer input. Input is in the minibuffer, not in the echo area. Completely separate - by design.=20 Maybe there's some particular scenario where something that _looks_ like "permanent hiding" seems to happen. If so, then it's that scenario that needs fixing. I see zillions of uses of `message' when the minibuffer is active, and input is never hidden permanently. And I don't see how it could be. I notice the Subject line of this bug says that `message' overwrites a prompt. If that happens then (1) that prompt must be in the echo area, not the minibuffer, and (2) presumably we're not talking about input in the minibuffer anyway. A minibuffer prompt is not in the echo area, so it cannot be overwritten by `message'. Sounds like you're doing something unusual, which doesn't really involve prompting in the minibuffer for minibuffer input. What's more, `y-or-n-p' doesn't use (hasn't used) the minibuffer. It prompts in the echo area, and it uses `read-key', which doesn't use the minibuffer. That's a main feature of `y-or-n-p' and of `read-key' - no use of the minibuffer. So you must really be doing something unusual, if not unkosher. Sounds like you've painted yourself into a corner and are now painting up the walls. Maybe you've dreamed up some kind of "solution" in search of a problem, or you've created a problem out of thin air, which then calls for a crazy "solution". > And `minibuffer-message' fixes it both ways: > when the minibuffer is active, it displays the > message at the end of the minibuffer for 2 seconds. Display at the end of the minibuffer input is NOT a fix. It can't be. I already listed specific advantages of `message', one of which is to interrupt your input and use the entire echo area to display a message. `minibuffer-message' has its own specific advantages, and thus specific use cases. It does not replace `message' and its advantages. > When the minibuffer is not active, it displays > the message in the echo area for 2 seconds > (the timeout is configurable). That too is BAD. Code should be able to control the interruption in the standard ways: `sit-for' and `sleep-for'. Those allow much more control than just a time limit for ephemeral display. > > Don't stop _callers_ from determining the > > appropriate behavior. If a caller uses > > `message' then respect that. If the caller > > does something stupid then fix the caller. >=20 > Callers will be able to determine the > appropriate behavior using new variable > like `display-messages-in-minibuffer'. I haven't seen the code or doc. But based on what you say above, about your "configurable" time limit, that doesn't sound promising, at all. Beyond this - there's no substitute, whatever you might cook up, for _also_ letting `message' do what it's always done. This is about backward compatibility, of course, but it's about much more than that. If you want to add some different behavior, you're free to add it. But don't subtract the existing, and very longstanding, behavior. Add your favorite new behavior as an _addition_, letting users opt in to choose it, if they want. Hopefully, any damage you're doing with this you're doing only in Lisp, so at least I (and others) will be able to undo it - at least by redefining things as they were. But it really should not come to that. Sounds like a sad state of affairs - not happy to see things proceed like this. I expect a lot of damage from this, at least to my use of Emacs and my code. Hope I'm wrong and it's easy to undo it. The right thing would be for you not to oblige anyone to do anything to retrieve the previous (since Day One), sane behavior. _Opt-in_, not just willy-nilly, destruction (or progress, as you might see it). If you push forward with this, and if it's not opt-in, please document explicitly how to retrieve the previous behavior, i.e., how to opt out. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Nov 2019 21:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Drew Adams Cc: Lars Ingebrigtsen , 19064@debbugs.gnu.org, 17272@debbugs.gnu.org, Juri Linkov Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157368060228166 (code B ref 17272); Wed, 13 Nov 2019 21:31:02 +0000 Received: (at 17272) by debbugs.gnu.org; 13 Nov 2019 21:30:02 +0000 Received: from localhost ([127.0.0.1]:60220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iV0DB-0007K0-Nb for submit@debbugs.gnu.org; Wed, 13 Nov 2019 16:30:02 -0500 Received: from mout.web.de ([212.227.17.11]:53965) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iV0DA-0007JL-2w; Wed, 13 Nov 2019 16:30:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1573680579; bh=54iA+6BZMPaJgbIcz7Ev7qoRSe0C8DjHzApHhOBOky4=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=ZQaYBo/XUnXy3qXMdsJxzAFXwuntlKZKkiMYu3WJqommd0LP8FzEWCmPaJG+bJNZS pIUd2v+H/f6KQX4hiIfbbzzr7p3HYg4MJeevNez5hqcZ/9EdzMuE30rRuMRyzQYdK1 MGInacYI/dshQR79wekay11VHmZO1NmCf8uxV0wg= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([94.218.222.9]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LpNwf-1hzUgA2PkT-00fAmK; Wed, 13 Nov 2019 22:29:39 +0100 From: Michael Heerdegen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> Date: Wed, 13 Nov 2019 22:29:50 +0100 In-Reply-To: <53c55db5-d623-4946-af2e-d141e7bc7acd@default> (Drew Adams's message of "Tue, 12 Nov 2019 15:34:45 +0000 (UTC)") Message-ID: <87sgmrpir5.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:LXVp1l94Qs+UrCZRsKNOA/AjNATaectwJedOx7AKz5OKkdPjNPB NQdJwlaJX2pzAVlNrG6AP/9lB94WMs12/cSHV8q42q9lNr7MsyMDwKJpufh9+H9tVhKQYvA EkXmCP+8mBvDPhtNnPM9+SBnNz44TCsROJIecKBNhuN2Y7WlPCTkYyl3CNlTqtpAWCbwAzw mrNcUIBRVxz134ojDUZHg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:xrPHe4OZh9k=:MwXBvPcTw2FWHSkGhNra+Y okoMhg04UHso1B6W7ia7c685hgbd6tWCULKyVBQtFi+TaRSrt1humiR9TGYhxLpel6zlafmf+ b8M9e+VGZfXSQ1zme+eQ9yKUHBnb3wqHtwo6KjwG12S3yXw5GfqszAHGkiQ9+4hN5+03CQDq0 KReZezta+6LhLjPKy6c97so1mfoOG/+8kL5VDmrWbooNJ+LMUGdePM8g4yeDquwSfoV8X5yvV KybzSa6jJ5ihKCHIrD1P6/svs4FN0OUZPs6lHfrjl48saAb4dakeTRE9JtRDYT7FcHGeJl/Qu tZeW2TYk09W+kH7ZOW4hw8NDLHygwv036RxC6tlLsrV27QpJljpwChviBexfiF3MtFKzSO3CR 85WtgZTIpvhXuvkZVopT07JpYph7w5CCtqNZpeFzCHhfXp7zTI3jA23B3tto4dIQMORtCFKoR 7Powtbw93EV5kWw31TN0IXng1Yv5D6XELEBHS8Ap6TXX30fiS9rkFW/n1DVHl3mWXbVYhOFiV 0Y0zcy3vTSiVcyoGaJ/9EOxTvtx9WeqtPKFpsFhWRFqtlniDtyHuHgBzY3Q5FcM4TJQA3Q/a4 svCaM+QZZh1ZTvbZD/DhDVn06Wr2lgYNJN5pRhWSGwVGeO0b/v76xhyemX4vGydutgzkrStiO jJfuZzjDHvRvFiRIRptOMy1dfvXlDShIa+SDm37PxaogqGC6yuLWmHknXqVKWZQfAF5gv+IyD 3rQ4wwz52wWi6GoL7vtmqDIJQCEERANWZ+H1N+3PHzYZoSSAxwl2DOEZ6M7fp2/HO5rTKM3km jDs5oEAzDCMW3aEYsZScylWN9X+6Y441PoQW5U/TPF5fGeSvf+/qW5kIMAg6oENgshTVP2mtJ MuCltlnkwsMxWm3adSm7A9J3wbW3WDCsWgOahb0B0g4A+L0vAfETgwQdmClBON1gx61Tblnum fGPhc6TRAoXIe59tN9b5pTOGqE4y4Nri7dgbjEOE5DeH4KoKdoZdJ6eu0lvOqSo6fMIWSft+O JJoXKBjVH5vHInccd8EwVeKtEY9eTBQMqenkrclOtSeOhQW5mOPnA0KaxJhhHt0HiztJPdGTr yoTrWB5GLfg8nHvHpLwbXRfHOfXmJ+2xrovfkKZ8GpCEIatxX+RGGPrzNirmBO7SIsuz3D5tx 2104fj2Pev5txWUmZwgO+mGNewIN+zpeKegSbE1ilC02jWzJk/0JVsxaNbETeIu7vsw6HNlh5 VGF53oXlNRoDDTXNOjoLD/MrtuxcLTxAhGM4yY8jG731TvjAIuSaqS5GHaOA= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > I'm sorry, but I can't follow this. I don't know > what's been changed, or why. (There are even two > bugs that are being handled here, apparently.) I understand your question as if you want to know whether there has some general magic been implemented to decide where to show messages. AFAIU the issues fixed were all special cases were a message hided some y-or-n-p prompt so that the user may have missed the prompt, or may have wondered what to do to get it back. > What I've said is that I object to an automatic > attempt to determine, when the minibuffer is > active, whether to realize the effect of `message' > or the effect of `minibuffer-message'. AFAICT only the behavior for these special situations have been made a bit more user friendly, and all other calls of message or mb-message are uneffected (is that correct, Juri?) so that third party stuff should not be affected. `y-or-n-p' has been reimplemented to use read-from-minibuffer instead of read-key, however (Juri please correct me if I'm wrong). Michael. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Nov 2019 21:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Michael Heerdegen Cc: Lars Ingebrigtsen , 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157368202330605 (code B ref 17272); Wed, 13 Nov 2019 21:54:02 +0000 Received: (at 17272) by debbugs.gnu.org; 13 Nov 2019 21:53:43 +0000 Received: from localhost ([127.0.0.1]:60299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iV0a6-0007xZ-OV for submit@debbugs.gnu.org; Wed, 13 Nov 2019 16:53:43 -0500 Received: from beige.elm.relay.mailchannels.net ([23.83.212.16]:10426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iV0a5-0007xK-0X; Wed, 13 Nov 2019 16:53:41 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AAF35500E84; Wed, 13 Nov 2019 21:53:39 +0000 (UTC) Received: from pdx1-sub0-mail-a44.g.dreamhost.com (100-96-6-183.trex.outbound.svc.cluster.local [100.96.6.183]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id CC5BA50132E; Wed, 13 Nov 2019 21:53:38 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a44.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Wed, 13 Nov 2019 21:53:39 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Shade-Chemical: 01c79ef2513dede1_1573682019143_3902361149 X-MC-Loop-Signature: 1573682019143:1665576802 X-MC-Ingress-Time: 1573682019142 Received: from pdx1-sub0-mail-a44.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a44.g.dreamhost.com (Postfix) with ESMTP id 5E49384162; Wed, 13 Nov 2019 13:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=PhUaamoQ5ZOOjrryXz40MlQIFfU=; b= mH10HDnOfN6hxm/KI7x2jsh6fZhD4hFCnpCIXTwTLp/5qSJHwBOaPYVIYn0Sycln CdQY2/EGfsD5ftkEm2D3puEVpf6N2Ds3iNuAwxiCyKySa/ZKZQeKxoQmvcpzcpz5 Za/QmLXDVmmWLQKafd5G/HgNRdRW6vLXsdVI3z9nP2I= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a44.g.dreamhost.com (Postfix) with ESMTPSA id E84FA85219; Wed, 13 Nov 2019 13:53:34 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a44 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> Date: Wed, 13 Nov 2019 23:53:14 +0200 In-Reply-To: <87sgmrpir5.fsf@web.de> (Michael Heerdegen's message of "Wed, 13 Nov 2019 22:29:50 +0100") Message-ID: <878sojjved.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> I'm sorry, but I can't follow this. I don't know >> what's been changed, or why. (There are even two >> bugs that are being handled here, apparently.) > > I understand your question as if you want to know whether there has some > general magic been implemented to decide where to show messages. > > AFAIU the issues fixed were all special cases were a message hided some > y-or-n-p prompt so that the user may have missed the prompt, or may have > wondered what to do to get it back. > >> What I've said is that I object to an automatic >> attempt to determine, when the minibuffer is >> active, whether to realize the effect of `message' >> or the effect of `minibuffer-message'. > > AFAICT only the behavior for these special situations have been made a > bit more user friendly, and all other calls of message or mb-message are > uneffected (is that correct, Juri?) so that third party stuff should not > be affected. `y-or-n-p' has been reimplemented to use > read-from-minibuffer instead of read-key, however (Juri please correct > me if I'm wrong). Yes, this is correct. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Nov 2019 23:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Michael Heerdegen Cc: Lars Ingebrigtsen , 19064@debbugs.gnu.org, 17272@debbugs.gnu.org, Juri Linkov Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157368751422051 (code B ref 17272); Wed, 13 Nov 2019 23:26:02 +0000 Received: (at 17272) by debbugs.gnu.org; 13 Nov 2019 23:25:14 +0000 Received: from localhost ([127.0.0.1]:60461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iV20f-0005jV-IV for submit@debbugs.gnu.org; Wed, 13 Nov 2019 18:25:13 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:58360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iV20V-0005ig-Dn; Wed, 13 Nov 2019 18:25:08 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xADNOA11165554; Wed, 13 Nov 2019 23:24:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=qJN8GHWhovALjHw49ILsfiNSyw9lsHBMUqMdWXSJlIg=; b=f62i5EUMp5vttoVB5pAofElEOaDUPrtksRe5NFYqa/Q4yx3Ib+eAsUNhPUbDQguWcPNr v1500nPctJFzeA/0kAOrcHYIEiv5AdUzDINImR4+TXKQqdTXtmb6HNNQjI1HhJMbuXT5 UbfWr9cnTJ6OCEJr9S+F2O4PTyu+YZOIhRymfmXbVRmIEa0qoWJar8Jv+XdpxYKxCibU mmC43xBBA5J93zy1YTCtytQrT+TkQMc8MAgUBHvrT4ZJOPXZX4PkdAfrO60IXZR6Il3T yxK+oIzl1MiLSgH3I4JnLAisjOKG/MkiV4n6uLN28YXOCOEIJjRXeOHkm5qJG5Ik3w4E 0Q== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 2w5ndqfu8d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Nov 2019 23:24:56 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xADNGHZ9107371; Wed, 13 Nov 2019 23:24:56 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2w7vpq40qt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Nov 2019 23:24:55 +0000 Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xADNOpju021144; Wed, 13 Nov 2019 23:24:53 GMT MIME-Version: 1.0 Message-ID: Date: Wed, 13 Nov 2019 15:24:51 -0800 (PST) From: Drew Adams References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> In-Reply-To: <87sgmrpir5.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9440 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911130194 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9440 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911130196 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > AFAIU the issues fixed were all special cases were a message hided some > y-or-n-p prompt so that the user may have missed the prompt, or may > have wondered what to do to get it back. I see. So the problem is that `y-or-n-p' uses the echo area for prompting, and `message' writes to the echo area. Yes, that's indeed a problem. Sorry for not understanding that that's what we're trying to solve. [I still don't understand why it's said that your minibuffer input gets permanently hidden, in that scenario. I suppose that if the result of your `y-or-n-p' answer causes Emacs to quit or to kill stuff then that could happen, but I wouldn't think it would happen generally. Your input is in the minibuffer; the prompt from `y-or-n-p' is in the echo area.] > > What I've said is that I object to an automatic > > attempt to determine, when the minibuffer is > > active, whether to realize the effect of `message' > > or the effect of `minibuffer-message'. >=20 > AFAICT only the behavior for these special situations have been made a > bit more user friendly, and all other calls of message or mb-message > are uneffected (is that correct, Juri?) so that third party stuff should > not be affected. I see. I hope that's right. I got the impression that a change was being made to detect whether the minibuffer is active, and, when so, make `message' calls behave instead like `minibuffer-message'. That would not be good. Can someone please confirm that that's not the case? > `y-or-n-p' has been reimplemented to use > read-from-minibuffer instead of read-key, however. I see. That sounds like a big change, just to fix the "special situations" you described. And it sounds bad, to me. `y-or-n-p' is not the only situation where we prompt in the echo area and read a key. If we're really going to make big changes, wouldn't it be better to do something different, to address all such read-key situations - aren't they all potentially problematic (special situations)? Why would we want to switch such situations to read from the minibuffer (activating it, prompting in it, etc.)? Reading a key (which is what this is about, IIUC) isn't specific to any particular _input location_ (e.g. the minibuffer). It can be relevant to the place where that action gets initiated (to maybe pick up relevant keymaps). But it shouldn't be associated with any particular expected-input location. To read a key, the prompt basically _tells_ the the user to hit a key. It's not looking to read any input into a buffer - minibuffer or otherwise. Why not instead just put the prompt in a temporary (unselected) popup window or undecorated frame? IMO there should be no need to give `y-or-n-p', or any other function that reads a key, interaction with the minibuffer. Just because we need to prompt, and be sure the user sees the prompt, that doesn't imply that we should use the minibuffer. No need and no reason to do that, is there? Using the minibuffer to read a key introduces unnecessary complexity and confusion for users. We present an input buffer for no reason - no text gets edited and input there. The minibuffer is a heavy-weight UI, allowing lots of possible interactions. I have a hard time believing that, just to solve the problem you described, we would end up going down this route. (A key can be read anytime - whether or not the minibuffer's active. And it certainly shouldn't require a recursive minibuffer if key-reading is initiated while the minibuffer is active for something else.) Using the minibuffer for _output_, as does `minibuffer-message', is generally worse, not better, than using the echo area for output (`message') and reserving the minibuffer for input only. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Nov 2019 15:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Drew Adams Cc: Lars Ingebrigtsen , 19064@debbugs.gnu.org, 17272@debbugs.gnu.org, Juri Linkov Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157374675713573 (code B ref 17272); Thu, 14 Nov 2019 15:53:01 +0000 Received: (at 17272) by debbugs.gnu.org; 14 Nov 2019 15:52:37 +0000 Received: from localhost ([127.0.0.1]:34994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVHQD-0003Wr-GM for submit@debbugs.gnu.org; Thu, 14 Nov 2019 10:52:37 -0500 Received: from mout.web.de ([212.227.17.12]:47343) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVHQB-0003Wc-K0 for 17272@debbugs.gnu.org; Thu, 14 Nov 2019 10:52:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1573746747; bh=J1QFFjfO0RUaXDYLMYN9mHxQW67K5sIDS292IwJk/Bk=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=bNtJ+CHNn7eqoybohOVURCA63vsXlIgS/RC+cWWPSJNc+6kqL7tXlyTtIoW9ZWZ0X ne/koqXTNMJjxNeEuuIqsbtmyxaqiCwch6ux+TeVibscxJUdUTz+HWN3uJQp680npa g//koUw3yzfg7PEPR+NefM12KPy4faUvLc13sNVE= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([94.218.222.9]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MVchv-1iNjjL2Lwl-00Z0UM; Thu, 14 Nov 2019 16:46:48 +0100 From: Michael Heerdegen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> Date: Thu, 14 Nov 2019 16:46:56 +0100 In-Reply-To: (Drew Adams's message of "Wed, 13 Nov 2019 15:24:51 -0800 (PST)") Message-ID: <87mucya2a7.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:R2SmSnh+kycZpTuk4cJlLe+YBHdAbg3r01bTyH4Wob4fGSc9/mp 5gTYinpQDI3ittiiWcd7m1p9h+I80Ye0hwpY0gl5y/GQzmW6VQSsqB1o84ALR0LVgCiFVck 097bQcNJhoWVJDd93lZgduWd3I8VTJpMEHRPXdQgtpLgNs+A5tw/5dxbpD4cH/Mizt/r0fG BZWPrW0Dw1gwiht6l9kwA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:EXsG+MYgIMg=:81xD15P0BzeS5iciM1osnh rqPbUN/9HMkceeM54ZsaaxiAfEncHwruSgwOK/lPoQfbXL/QFo18ydBb7gidPKiE+bSK01aiF QvooYmNBcnR+eH7hf2g7tlNddTAnGTEl3Ek6AldvBoAIMz1wh10ffeDiJbinq9Op/+w7IAu0+ D2WLfK5LasDCRmnrc3gpltsAKCeZfejCDcEfWOFP+ALEVAB2yFoLlbB/mx+MF3Ipu3JfWYeW7 +ELX6J2ddpPCh36aabwV7lYy1i97bxqVEsyUOs/9j2+4MzwLZSK7h0nMlaSlurY2LldLkNlJr PNi5QrzykvtEmeZ679ZfzUKmX75xdEofZQ9CuZ61+wynOYbyWbjWabdKZWqlEWV+hl+Al192z 7hnTDeUYZf99H9jnmGT01YG6tiWYQQc6bmMGPBy4CbyxsH2QswvfwDK4AP8kNy2wGL1u9pJqQ Lv4rDvje5E3QMk3D5YxF3DjjkvBwbKSTLZL0wmtARUHWzVm4S1G+ERVpsAXz6bbWfHVygmz21 l0i5itg/uvSXrNciXpZGcrSmj+07S9hju6jKa0INjMsislryy+tr+ydh5XKNgCcsC9dkrV17/ rX/Tj8QjoYki5TCtJOKbDuKaQ+pRhxWZkW+aPPSCf1PT7NuZI844/nDRYZ0UBwJ7pkV3zswae u/jDy4oD6xfjxhIk9o7hPNQg0wlaZNa8RT0sFZQincNR919SLp68ANblvh1vTltjc2yLOAT+1 /vRr1Q5ufRL8MsUaYac87P4cmTvHaj+eL2fjBB4x3oAyzlAJakB12Rw+D8lZ7YPxHFMnRCjKR vP8c6qH9PXDIeVBVwFe0dFUM5lKSdoXPUc5gITq1lfxv7AKBsgMcIM9mPpVxvneMSQvanh9yy gQKHC+0WHT7p6/4wPAz2HT3xb4EXgocHUzifRRPsaaQKBTi8Y+GoOsBhx+A9ZMWPUS1KhdBmM iKIA6yA7AV0M7ahgsgbHZqtZp7aaQs8i0tBZNcoIu6V8T6m5MJwctD3rXWYFz4PluJMFu1BGf 0m2TCiVT5IZFYzDtusL4nRBEVgFWYYhMJRBim6BI8Xjr3/W49T6a2PkRaCU/Vi1T2hMiB/cYI cKKtwOntCQl/rzw+q4KAdK1a9fnG1cUP76o4ImZxNb+k2ook/E0yyH9Dwgoar6gQjnjuUHhiQ 7oameN7TZbWFfC/TWlUK/uQGc7jyp94wCyOg5GjvBEQcJyZ68wF5oiLcOLgyjMV+5N3Npf07g Da5snSnHj7Uv9OTmlOc++5YVt4VwoargTszUmaWBzYosP/jE+UGE0KlPGPcw= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Drew Adams writes: > [I still don't understand why it's said that your > minibuffer input gets permanently hidden, in that > scenario. I suppose that if the result of your > `y-or-n-p' answer causes Emacs to quit or to kill > stuff then that could happen, but I wouldn't think > it would happen generally. Your input is in the > minibuffer; the prompt from `y-or-n-p' is in the > echo area.] You misunderstood the word "permanently": We didn't mean you can't get the y-or-n-p prompt back but that the prompt doesn't come back from alone without user interaction, no matter how long you wait. > > AFAICT only the behavior for these special situations have been made a > > bit more user friendly, and all other calls of message or mb-message > > are uneffected (is that correct, Juri?) so that third party stuff should > > not be affected. > > I see. I hope that's right. I got the impression > that a change was being made to detect whether the > minibuffer is active, and, when so, make `message' > calls behave instead like `minibuffer-message'. > That would not be good. > > Can someone please confirm that that's not the case? I think Juri did that. Regards, Michael. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Nov 2019 16:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Michael Heerdegen Cc: Lars Ingebrigtsen , 19064@debbugs.gnu.org, 17272@debbugs.gnu.org, Juri Linkov Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157374894817558 (code B ref 17272); Thu, 14 Nov 2019 16:30:02 +0000 Received: (at 17272) by debbugs.gnu.org; 14 Nov 2019 16:29:08 +0000 Received: from localhost ([127.0.0.1]:35086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVHzY-0004Z2-14 for submit@debbugs.gnu.org; Thu, 14 Nov 2019 11:29:08 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:38440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVHzT-0004YL-Cs; Thu, 14 Nov 2019 11:29:05 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAEGSuLv187675; Thu, 14 Nov 2019 16:28:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=/EEDpq0DGTAYunnCae2/wHP1+wFmtKAn/hz2ZjD+Me4=; b=EqPYNZs3iKXKIoB1bwcXEwzTW7PlnKZY8K4DOpGhMWaf5Sy5nH02N3iH2LRNMVO8HsuX Q9rWYmswo+3n6m/DoPZLWYbHmXjZ8ebLZ/pEjPNUT2f3voolVlzc+Me9f54t5YKBoz0T mAe2icYGw2GOdISYccuAnGgI0DIKCz2+VwcQsQ0sWkOs56k892FVSMRoeeTrMkNmnWlp UwmKm5HJfS3J+KV8SHIp1CJGgwLTL4+CYA8HhRFKllbyZugjleAq5SFwkBiX+uofTES2 hy355ISKqXf78k2D2W7TtKqwKLCd81B0fHHg8KypcPG+1sxqDeVBcc3IPSLj+1Ur+obL lw== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2w5ndqmc2m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Nov 2019 16:28:55 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAEGScH2031885; Thu, 14 Nov 2019 16:28:53 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 2w8g19nde1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Nov 2019 16:28:53 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAEGSp8D014784; Thu, 14 Nov 2019 16:28:51 GMT MIME-Version: 1.0 Message-ID: Date: Thu, 14 Nov 2019 08:28:50 -0800 (PST) From: Drew Adams References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> In-Reply-To: <87mucya2a7.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9440 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=884 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911140149 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9440 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=953 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911140149 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > [I still don't understand why it's said that your > > minibuffer input gets permanently hidden, in that > > scenario. I suppose that if the result of your > > `y-or-n-p' answer causes Emacs to quit or to kill > > stuff then that could happen, but I wouldn't think > > it would happen generally. Your input is in the > > minibuffer; the prompt from `y-or-n-p' is in the > > echo area.] >=20 > You misunderstood the word "permanently": We didn't mean you can't get > the y-or-n-p prompt back but that the prompt doesn't come back from > alone without user interaction, no matter how long you wait. The statement made wasn't about the prompt. It was about minibuffer input. My reply was that input is in the minibuffer, and both `message' and `y-or-n-p' write to the echo area (or at least they both did), so I can't imagine how minibuffer input is lost or "permanently hidden". > > > AFAICT only the behavior for these special > > > situations have been made a bit more user > > > friendly, and all other calls of message or > > > mb-message are uneffected (is that correct, > > > Juri?) so that third party stuff should > > > not be affected. > > > > I see. I hope that's right. I got the impression > > that a change was being made to detect whether the > > minibuffer is active, and, when so, make `message' > > calls behave instead like `minibuffer-message'. > > That would not be good. > > > > Can someone please confirm that that's not the case? >=20 > I think Juri did that. I didn't think so - not explicitly. He confirmed your "AFAICT only the behavior..." description, but also your statement that "`y-or-n-p' has been reimplemented to use read-from-minibuffer instead of read-key" statement. (Or perhaps just one of those?) There are mentions in this thread (and others?) of `minibuffer-message' being used in place of `message' when the minibuffer is active. So it's still not clear to me that such a change is not being made. And I disagreed that `y-or-n-p' should read from the minibuffer instead of reading a key. I guessed that the problem that that tries to solve should still exist for all uses of `read-key' that issue a prompt (which is probably all uses of it). No? A general statement that "third party stuff should not be affected" is great, as far as it goes. But I guess I'll just have to wait till Emacs 27 to see the devil in the details. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Nov 2019 17:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Drew Adams Cc: Lars Ingebrigtsen , 19064@debbugs.gnu.org, 17272@debbugs.gnu.org, Juri Linkov Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157375122421603 (code B ref 17272); Thu, 14 Nov 2019 17:08:02 +0000 Received: (at 17272) by debbugs.gnu.org; 14 Nov 2019 17:07:04 +0000 Received: from localhost ([127.0.0.1]:35143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVIaF-0005cH-DL for submit@debbugs.gnu.org; Thu, 14 Nov 2019 12:07:03 -0500 Received: from mout.web.de ([212.227.15.3]:53629) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVIaD-0005bh-LE; Thu, 14 Nov 2019 12:07:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1573751205; bh=fig1cgkFzmCNMAwqpyUgPhVZljXO+REHXIYWjGZfcd4=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=rQGA2F+f7jtw8OipjS6llSeJwmj2d/9qG6717XU+gm83lIKIms5vcYgKtJEAaOqJb uCqAnfVm9wH/TcC8GpZCunnkwF4VMGF90Ou1gm+DleMhAQyxZvwayk6E2nINsbdjuZ YVLWO1hNQ+Z5pNQL2feNk0k24SyJeBip1b4nJna0= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([94.218.222.9]) by smtp.web.de (mrweb004 [213.165.67.108]) with ESMTPSA (Nemesis) id 0Ljgd6-1htkq43Xfk-00bedZ; Thu, 14 Nov 2019 18:06:45 +0100 From: Michael Heerdegen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> Date: Thu, 14 Nov 2019 18:06:57 +0100 In-Reply-To: (Drew Adams's message of "Thu, 14 Nov 2019 08:28:50 -0800 (PST)") Message-ID: <87mucy4cb2.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:7qmbO4MYF7fPbHTih6BNbaWOTlsHqMcwCmoYa7ldS3ZDMoLaVpF cQCReHA43caXHxOsAniah0Goq1FQbhr8AJdhylDClKgTjHC9Ns/LUXtROXnjtB32x41974H txIX8nWGCoFAw2b/TrOMR+3NfHcaTUB60YigkPWOOfAIvSMYfvcwGHNkJV5GJKE8E3XOKS0 qYppZMx12RSKtSe3IeQTw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:14VSYp0y/VM=:BsLcSC5TfevL/YejNmz3yc ikrdW3oQNsbHl6+0/RMsDYC89+xTfUdoCPujTgDc3zarOwMBH7BtBZ6Gm0vUxRTWVWjBqqVXo 7mjkSul3aF/k1Ncp6goFnwGtykmyUcDxyjhK15I0c1/HjebzcANU/MwtAy1aVYIVoVx373tm7 XL2B9SuJCdl0JGpGBFgn2iTKlsx5Cro3yMjVDVGOfMB4k3ajuz/oiPzxTBABbwHX+EjUzdpEr v1G2rB0Qw2Bw89uKmAIg+2GSJTfwkyDZywsKLXpwNuvlpUxqS61t5tDPC12HXfYS4rd8fzuAs AfIFPFho70thz2D/YkYj6BispZlmdzSSm78l+NzNvhc555kDEMXnZ/HIEwp3z0KlpYIB/xXsK q612QTOyyR84wsLN5aJtb7U6o/eIy9UKT7BeYWMqBLtPvAgx515ayJraK4R5d+3xDDp2qDkyc 5r6yKMC5+FV8UYeQblE3GbvYfVpEGjq7QsQPIydNnezldWJVo48Pdy4U1nqLlG0NuO+dGGRbI How1Gi7AxTHLCNYiQ1N5yFulREynlhfU4L7wIaeZbr88BMZbb34qT6XF3GD1VPrrRUuZkCbxH j23iR8cWCiS+0+9grSGo3Af68kKXw16cFqjU+8OYRxegTfxF07IB6GjR7WHvZJCJ9U6862pzY G0QNT5bPChY17aJNxTYtT1/bM+Fu+uLGxsfN6d22pdWiGmK9nXdefRoSt44dKwzkmwntz989W +0W3q7dN88ogD76aMT9np9DMKtwMw6wWrUGJbbuzNGcD33Wnr8q2gE79XlYuEp3tiMgx0YuHY GqHwM43KBKPMZuRBGbKOT4q46nO+X3WCKi1HOF8VAGbrE0yVcPhtQOID1RUHemM2f5xBZb6Zr 1TiCOiV4BPD4DJWJMweUp6R0V3PgCzc7pESwgV/VW9IKJf/nS2AU1VvEookzSpMwsFioFFRw0 TfY1YBr71Em1KYhVosMazYNszl04AwPdP/zs3cZ1wp1j58V7EsD9JCBEacKX7ssHUG9P20epT oyiZIGr/5O4q6287HOb88gj+vgFD/3pEIXVJPw4rpB4tqF1flEp9KNdDSd3JXIw/r8IYNJvYh jtwpqA9Jk+qPqo73OnMzob8WwglkfJpN3Cq6x/NfBIlnHKTqNc/4K722IMp6TXJ6/ySALxLLG qDmFgxuRIjKAOBOeeRPlGhRodnEyvyvrvEIfniMvkZ7lsg65Ir0F4Rzvhz2Vq3uCHk7f5WFb2 j4KNc4VY/RXsc8GtRd+oGr0Ctaw0SKwbln/S/zK+N+CdrFCzSUa4q+fRRZNs= Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Drew Adams writes: > My reply was that input is in the minibuffer, > and both `message' and `y-or-n-p' write to the > echo area (or at least they both did), so I > can't imagine how minibuffer input is lost or > "permanently hidden". Ah, ok. I think the posters just confused minibuffer and echo area for the case of y-or-n-p then (at least did I). > > > Can someone please confirm that that's not the case? > > > > I think Juri did that. > > I didn't think so - not explicitly. He confirmed > your "AFAICT only the behavior..." description, but > also your statement that "`y-or-n-p' has been > reimplemented to use read-from-minibuffer instead of > read-key" statement. (Or perhaps just one of those?) > > There are mentions in this thread (and others?) of > `minibuffer-message' being used in place of `message' > when the minibuffer is active. Yes - in the reported situations, not generally...maybe someone could send Drew an accumulated diff of all changes or so? > And I disagreed that `y-or-n-p' should read from > the minibuffer instead of reading a key. I guess this can be debated - I don't have an opinion so far. Michael. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Nov 2019 17:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Michael Heerdegen Cc: Lars Ingebrigtsen , 19064@debbugs.gnu.org, 17272@debbugs.gnu.org, Juri Linkov Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157375188022583 (code B ref 17272); Thu, 14 Nov 2019 17:18:01 +0000 Received: (at 17272) by debbugs.gnu.org; 14 Nov 2019 17:18:00 +0000 Received: from localhost ([127.0.0.1]:35161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVIkp-0005s6-Tg for submit@debbugs.gnu.org; Thu, 14 Nov 2019 12:18:00 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:43488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVIkh-0005rf-FB; Thu, 14 Nov 2019 12:17:57 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAEH91R8030294; Thu, 14 Nov 2019 17:17:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=QmrP2toYlYlU+u+QI9kjakxuO4jpLWvyaTJJtzO9XLg=; b=B98QxxnZOZoEqgoXwJZulDscGyDZPFgrJmcFkZI/Cfk3weQzX2wO4YT/yG656vrb0ZhE KOjWDwrEex+8lNOLAuhJ2pRXoVhsoLMdlNwhcK1f8wKG9DSbLC4JP85q+tDDYhJDqUMH 0dt5dP9eTf06USwfuoUu2hM1RgFOsckMOlRmN2YXDmNFZJrRmzh3LA5z7G6Bl6HRWZvj 50a/jNnd/YSg5rna4LEBa4cuN6qMPZCwMaDZ9OCjvXdOvRi/Pf1rBNo8MuNCoVKtnBrH tYY1JpsRhlkkWxbKOoDy18LPF38jzw6ALPD7pB1PXNYVTGi2NIAb7A9gOXJ4xSVSCg8B PA== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2w5ndqmp18-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Nov 2019 17:17:42 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAEH8aqc151026; Thu, 14 Nov 2019 17:17:41 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 2w8g19qpph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Nov 2019 17:17:41 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xAEHHaOv018958; Thu, 14 Nov 2019 17:17:39 GMT MIME-Version: 1.0 Message-ID: <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> Date: Thu, 14 Nov 2019 09:17:35 -0800 (PST) From: Drew Adams References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> In-Reply-To: <87mucy4cb2.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9440 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=634 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911140151 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9440 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=699 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911140151 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > My reply was that input is in the minibuffer, > > and both `message' and `y-or-n-p' write to the > > echo area (or at least they both did), so I > > can't imagine how minibuffer input is lost or > > "permanently hidden". >=20 > Ah, ok. I think the posters just confused minibuffer and echo area for > the case of y-or-n-p then (at least did I). That's easy to do. But the statement wasn't just about the minibuffer when echo area was meant, or vice versa. The claim was that _user input_ (not a prompt) became permanently hidden. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Nov 2019 20:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Drew Adams Cc: Lars Ingebrigtsen , 19064@debbugs.gnu.org, 17272@debbugs.gnu.org, Juri Linkov Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157376339315295 (code B ref 17272); Thu, 14 Nov 2019 20:30:02 +0000 Received: (at 17272) by debbugs.gnu.org; 14 Nov 2019 20:29:53 +0000 Received: from localhost ([127.0.0.1]:35305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVLkX-0003yY-Gk for submit@debbugs.gnu.org; Thu, 14 Nov 2019 15:29:53 -0500 Received: from mout.web.de ([212.227.15.14]:44745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVLkV-0003yF-QH; Thu, 14 Nov 2019 15:29:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1573763373; bh=IOJUjY1ulJtJWSdD+8LoZANAmZvMUgtIFPmpr6DEl5o=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=ddWYPgV1Y3sET4pX59BRdKaPL+nFI7byoGmURCZfLQOr1nC7tLs9PS7IRMEBOeB9B pk9UTGo8uWf5jvMMmZxdL5321ZbwkwPNg4thf+5PTtCA8lspK9UKqZJSBEJC6j8bqI 0YQl2rvtg+WrosUzxIJqP5KPMQUJkbWPp1uaVhv0= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([94.218.222.9]) by smtp.web.de (mrweb004 [213.165.67.108]) with ESMTPSA (Nemesis) id 0LdrkJ-1i53XC2Mgl-00j3MA; Thu, 14 Nov 2019 21:29:33 +0100 From: Michael Heerdegen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> Date: Thu, 14 Nov 2019 21:29:44 +0100 In-Reply-To: <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> (Drew Adams's message of "Thu, 14 Nov 2019 09:17:35 -0800 (PST)") Message-ID: <87k1822ocn.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:0QG2qpnF2ov98aQzuKh25RXa1sbNrHRKMe3i1K7z7/pS1rSnfX5 MUiYX+UiWUpXT+6yJoPw+udnBworfHAZK+8SgAlgNKErYrJZQwGMQ/4gjEgWSM0ZisjnIQG /mAwSosENc913JHvf9cyHWh2nDVMLkkw1eoF7yH+jjeHSa263c8Aii6CqHWk9ZNaTomoiSl 8hl3QJwabGossMMMyPKCg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:w53or4D/6to=:ILMGsfVf9V/FyP3fqmQHlG xKgPoRJrLxLVfywKbqHFPJ8hYtyNSyXZpAOGft8zw/QsVk7bjhMzHUEC6EV+QbNprjEokdJYo XUaojSdH2tOBo4af52MwW72teUP3mXnHDHL45uC89XBjYoPAvGVfU4uyaJ/d5D1v+0UDjM5eE sFxDbaOWDWJtv/uzG+A0JOKqBPa8e6Tg9ej9XqiEiCUqvQb5TR+PEa2Ot0UoCbUHEWQgFR435 YtyVDdX1wG34C+tvFqkOxuWnuF6jKiKdQoFuROdKObEThMP204ztijAd5OhM6gAohuhXZNHFz PGxrDbADX1E1OMN8NyIzbxt42qUWm8K4NM7BV9qvjebqEZ/V94w7W/EqFvMcx5YlZC19h1cZ/ LdQrBEenhAdVlEkgZPWhgS8hdvBlCbWsfwHmQ9Y0FJo+yEbShj2lJrUMXw9gCivb9N/2jZn/O 7t5Im/oJgcdB/rdqDfEjWBSI1u6QUoGhRgRWbecbMC2k4ASvWla8AazlRtoyR7k483bEWgu/t znMfhagXeXiE+L49nQFrP8KvtKtKadFNYKnE6mQH3l45ojSmMtLtQLAnnuzA+uEkMtAsBMXR5 jEfDA8qv/zHvKfum4MB/fhdtNft22tQo1s6SnPI4rEQTeUy1T5ZhKOjN0JI9X8O2xOiFLgit2 45we9ezyre+rV+yI4IbgqqUInPofYyI/NPV+Ob0g4vN0DJPHm4O7y9Fb78lOqrmj/DwXwgNtR ocS0kygw4GW6Ca2KoZCQt1fFtEJDVwLYakLKhUBSVIce9PaTG6IWtvTk2p6T0J9kJbUAjOVM9 YJrdJC42mPMGQ7RmvXQ9h/upgnVyqD3rcD8+cjaKL57CGyuoh2khZNPo0DjLilUIC6Sefm2sM 7ao4NxLIPkP8zLBqJD63YUPZLktDpth9/jqwS+GZs924aPGex6AmIdTid91ViSC/1ALwk0/hX wHvzTpQdMIWSQtFIGsbOveh0ktRiPhhE/QCrU2CS0X26O6zgAviDg/OgA8yuoGoSXetzN2EMY hqACiFBpWu4vgKsULUV0HqMFRXoPRSN1YDRdNUG60qcYFvbQKL4X4vDm0u0k+j9RudCvnVnn5 YrUMq9Te9lJ7UL08Z45Ijfp3ZO4mV6OLjzxehi4iW3zTEyUJ8+FSyJ2bFpIJ/Eu7dtBa5tO1t kd60O1hRVCwzG6RJ41nXqb/U5zXzgqu8b3/o2aqK/XVZ5MRzfvdFgwAu0wjSwVaEsi/uLZYuN McrDK7z+oNWIKNBBg0I2bZHhpmmaiy80kbARZKP61zuRaSFTrrhwrj05V+DE= X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Drew Adams writes: > > Ah, ok. I think the posters just confused minibuffer and echo area for > > the case of y-or-n-p then (at least did I). > > That's easy to do. But the statement wasn't just > about the minibuffer when echo area was meant, or > vice versa. The claim was that _user input_ (not > a prompt) became permanently hidden. I don't know if that was also a mistake or really meant like that. Michael. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2019 21:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Michael Heerdegen Cc: Lars Ingebrigtsen , 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157393849022115 (code B ref 17272); Sat, 16 Nov 2019 21:09:02 +0000 Received: (at 17272) by debbugs.gnu.org; 16 Nov 2019 21:08:10 +0000 Received: from localhost ([127.0.0.1]:39790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW5Ig-0005kc-47 for submit@debbugs.gnu.org; Sat, 16 Nov 2019 16:08:10 -0500 Received: from azure.elm.relay.mailchannels.net ([23.83.212.7]:46073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW5Ie-0005kR-D3; Sat, 16 Nov 2019 16:08:08 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4256E141730; Sat, 16 Nov 2019 21:08:07 +0000 (UTC) Received: from pdx1-sub0-mail-a75.g.dreamhost.com (100-96-89-221.trex.outbound.svc.cluster.local [100.96.89.221]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C057F1411C4; Sat, 16 Nov 2019 21:08:06 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a75.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sat, 16 Nov 2019 21:08:07 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Imminent-Glossy: 54e8be703485e954_1573938487025_4138393681 X-MC-Loop-Signature: 1573938487025:4031513100 X-MC-Ingress-Time: 1573938487024 Received: from pdx1-sub0-mail-a75.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a75.g.dreamhost.com (Postfix) with ESMTP id 76EA17F705; Sat, 16 Nov 2019 13:08:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=+pf0fb0CEAqGBkduS7O51B8dvFE=; b= YOr8bcQzjCI1U37QyXZ81y4dCmYcr+9Hz/jgrpxc9lryplYCchHoKRNZkJE5033N uNDKA1hYt60WqgMAs6s0GFFdhQjvEfqEr5esTNf7MfSNBX6/JpkNibGKmk3nyCD3 SQIC3p5mgxflfZibnw9uW/ae9JO9lvUBc8X2Slf31wo= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 83D527F702; Sat, 16 Nov 2019 13:07:56 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a75 From: Juri Linkov References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> Date: Sat, 16 Nov 2019 22:53:51 +0200 In-Reply-To: <87k1822ocn.fsf@web.de> (Michael Heerdegen's message of "Thu, 14 Nov 2019 21:29:44 +0100") Message-ID: <87lfsfmtk0.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> That's easy to do. But the statement wasn't just >> about the minibuffer when echo area was meant, or >> vice versa. The claim was that _user input_ (not >> a prompt) became permanently hidden. > > I don't know if that was also a mistake or really meant like that. This is not a mistake. Permanently hidden user input is a serious problem and security threat. Today I started compilation, then in a Dired buffer requested files deletion that displayed the prompt: Delete D [54 files] (y or n) But before I had a chance to answer the prompt, compilation finished and obscured the prompt with this message permanently: Compilation finished So I forgot about what was in the prompt :-( Since Drew doesn't want to improve safety to cover all such cases, we need to address these issues one by one, so here is the next patch: diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index 5a3386f227..101e294557 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -2265,7 +2265,8 @@ compilation-handle-exit (msg (format "%s %s" mode-name (replace-regexp-in-string "\n?$" "" (car status))))) - (message "%s" msg) + (with-current-buffer (window-buffer (old-selected-window)) + (minibuffer-message "%s" msg)) (propertize out-string 'help-echo msg 'face (if (> exit-status 0) From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2019 22:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Lars Ingebrigtsen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157394387630447 (code B ref 17272); Sat, 16 Nov 2019 22:38:02 +0000 Received: (at 17272) by debbugs.gnu.org; 16 Nov 2019 22:37:56 +0000 Received: from localhost ([127.0.0.1]:39852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW6hY-0007uv-AT for submit@debbugs.gnu.org; Sat, 16 Nov 2019 17:37:56 -0500 Received: from mout.web.de ([217.72.192.78]:57857) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW6hR-0007uY-H1; Sat, 16 Nov 2019 17:37:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1573943858; bh=9okI2I6++jTdMorPh72NxKL3IoE1OLQxYzdgMyOST7c=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=qui5O3jUyG+BJjVhTe+I7g/ClkkhPuqr6skvp6G7zPD9o9pUH7d7ehKSrihbk8wIU Q5ZZhSCZaPO3VVD0SlAS3i8+hrWQodNLgrZ/rrX5Tobi+udqfwZfmyKbv0eRCaS0j6 mBu9/U72xeDCaXsWuonfz9kJjAq0y3Qys+yhVx2c= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([94.218.222.9]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MfYn9-1iD2PS3Wzj-00P5wJ; Sat, 16 Nov 2019 23:37:38 +0100 From: Michael Heerdegen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> Date: Sat, 16 Nov 2019 23:37:49 +0100 In-Reply-To: <87lfsfmtk0.fsf@mail.linkov.net> (Juri Linkov's message of "Sat, 16 Nov 2019 22:53:51 +0200") Message-ID: <87v9rjv45e.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:i1huyGYgTICtPpHk1F3QZB5iwGd39o1s+7iLMUuK3mErCJmrvcS uHllZmgmCt73azmRnd0kwHcRaeZuNHa+nK/31XqDeG1TtQr5YNpH7oXBYbBVlwOtIRC4UHR GGMjUXJBKeEO8z9Q/Ov0e7ziTF8rAm2d64gU7656baq9XacwgTvrByO5VgeShCasxfo6Ms8 E/kmahIgh2mvUmm1fRXrg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:76nwgFjTDU8=:ssWILUHgFyiLDoEmofZGGn XLz+d1nZ43lcGY2PxCBWHPjilOSaqWkX0l+oS8VfsTF/nDza4uk9xqphfS/oaDEFRv41LFMDU dS0nV3xJI+ErpkJ3tg4xCJ6eBHU9BQhPIQmH1ME7jBrMMbUEkKu+osAfatO8lR31ICo1cylIu U7yzmbEsc8RmvE3wsvqt478HFSOu9suFxvEZhZSZJxx1oO3J45hghfV4RqqntZkb09ZOQE0sR nNIaBRQh4hUz9f3sIM3EwGuj9aISyadrw7Rf61VfyYkDyh9cFkXhtuzBOGOjR/fnzWVriKEJa D9dy5DbY3EPOTOXmTzODbU2skbqoxtk/e8k9DEOg6SjrAuoDoorqLK+bFTZ/UillCM/ah+uuw Q6C9MLz734c+pCxhURywsrIDPcfohMeNTlkpiRNbJ+1Uj4eLGx7xU03pjOU+CVq1uYCn+Hoot sDgeqcfxcJsGkrTUdhLNUn66q3y0RrA4FW3nUNwNFP+4vasfT75+xa4i1GxUuXOTlCYz6epn2 83gJ7N/SVT3JrnJblPt5KUWAoywPH3Tcu58/OLZEEdSgmvK2zifBwKimFnRN665kcNJoypMD/ m0fwnaT6y4pYDnQBUF6o2EWWoDbWNKSsqSDbxBA1h2D7bXhE7eIPAdkDo+IcwrP+uBZ1TMwpm XDyqnF6ffN5Y/hSlI40db5SBHAWdVw2wUtfoqC6BKkEvVlc4h0Uh2RzDxE2mPhXbiEGg0jV6c 0XnU0WMiGQsdYMot9hGZxSR6aHDFct2/zybLPhigEucv5N5bT82gv7VX/uGlPeM+F8YI/egBO cmN3fZzWxmaMRyZvLy97/64ylCSfHLtXO+nlm37SFiim7MqfBR79+QUGjdIikP79o7rqWaKNI Z3fS+p8kvz8vup4bAEk5lBLUWl9yFa27BrZrWZfU24ePshiUqHr9xKfxYuyj16J2RUUeR5LdG RPhNXG7d7x/qMIOxlWtg70OQ/EbaH8F2smkKxKhcbUkltoLgmtKUxJHcgSEMvn/oIv2pd9j0d /1cqLaQHxwBKXhc5edMOmq5pzi94yrOBH2KAD12k2tRL2kMXC7n5a8+4DYq49WOfiZLfyGkx4 1a4a6QNWp1ErURw/XtwRMVNWBbPYazApUe8s89oQ5yFTtcoE8mkNVsZQNlY3uQafGBC0q370g znYQX//QOTQMK2u9oOq+ihJHQDXHyN4mSPTj2uhKb0k5YxSoxj6hmK2Pieor5obKmFZwx37Ty /A67+kI0ntSCq07yUoGg39TQnYwQK5nJF33l8Dk7qwAu5Q+NXYO7l3sPwFNY= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Juri Linkov writes: > >> That's easy to do. But the statement wasn't just > >> about the minibuffer when echo area was meant, or > >> vice versa. The claim was that _user input_ (not > >> a prompt) became permanently hidden. > > > > I don't know if that was also a mistake or really meant like that. > > This is not a mistake. Permanently hidden user input > is a serious problem and security threat. > > Today I started compilation, then in a Dired buffer > requested files deletion that displayed the prompt: > > Delete D [54 files] (y or n) > > But before I had a chance to answer the prompt, compilation finished > and obscured the prompt with this message permanently: > > Compilation finished > > So I forgot about what was in the prompt :-( > > Since Drew doesn't want to improve safety to cover all such cases, > we need to address these issues one by one [...] That's nearly impossible to do, and once you are done, new cases will likely be introduced in the future. Drew, how would you address this class of problems? Michael. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2019 01:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Michael Heerdegen , Juri Linkov Cc: Lars Ingebrigtsen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157395494114497 (code B ref 17272); Sun, 17 Nov 2019 01:43:02 +0000 Received: (at 17272) by debbugs.gnu.org; 17 Nov 2019 01:42:21 +0000 Received: from localhost ([127.0.0.1]:39929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW9a0-0003lf-D0 for submit@debbugs.gnu.org; Sat, 16 Nov 2019 20:42:21 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:53792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW9Zw-0003lM-Uo; Sat, 16 Nov 2019 20:42:17 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAH1dZDX081391; Sun, 17 Nov 2019 01:42:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=whZXLrGhQ3s2MbmlZbsvYWQNFR5IhHdO6m19EBqgbe8=; b=ciU/Lv8f9/h+kvnDdSIwWb6WxESBm26XszVviRhFc7WhEV5QIuRqbKFDKBQKd7SKQqRl QsWW127FQR9NR08tcS3nxSRT+AxGoLgTHBj2h0Bson4T/k+JKU187u/KQuYMEGAi7ufw jWqWE8SZuf1mKy1n46QCF0aj9WI6c48xo7UK+KKVaz4U6RQ3bZoCp3QSBhT3u/6r40C6 tpr3SWd+1njboZ4gwe575yOTTmlyy+FvWX1oT98ciSgzqw7koYQrA6wzAgiaQ8hGOnfK I2PSbGk3MEASjGaBN4NzLIW6QObjQ8IN3QSWkD6vlia7wPm6YXiZKkh9/iV4FMEg06Rs 9g== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2wa8htacer-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 17 Nov 2019 01:42:10 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAH1X7aJ108885; Sun, 17 Nov 2019 01:42:10 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2watjv4emd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 17 Nov 2019 01:42:10 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAH1g7oc008775; Sun, 17 Nov 2019 01:42:07 GMT MIME-Version: 1.0 Message-ID: <266012df-8baf-469d-83b0-25f9cfdff603@default> Date: Sat, 16 Nov 2019 17:42:06 -0800 (PST) From: Drew Adams References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <87v9rjv45e.fsf@web.de> In-Reply-To: <87v9rjv45e.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4927.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9443 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911170012 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9443 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911170013 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > >>> I think the posters just confused minibuffer > > >>> and echo area for the case of y-or-n-p then > > >>> (at least did I). > > >> > > >> That's easy to do. But the statement wasn't just > > >> about the minibuffer when echo area was meant, or > > >> vice versa. The claim was that _user input_ (not > > >> a prompt) became permanently hidden. > > > > > > I don't know if that was also a mistake or really > > > meant like that. > > > > This is not a mistake. So you're saying it wasn't a mistake for you to say that _user input_ (not a prompt) is permanently hidden? In that case, what's the scenario where user input is permanently hidden? My claim was that I don't see how it can happen that your input in the minibuffer becomes permanently hidden. Michael guessed that you maybe meant that a prompt, not user input, becomes hidden. But it seems that's not the case, so please provide a recipe for the permanent hiding of your input. > > Permanently hidden user input is a serious > > problem and security threat. I'd agree with that, of course - it can be. > > Today I started compilation, then in a Dired buffer > > requested files deletion that displayed the prompt: > > > > Delete D [54 files] (y or n) > > > > But before I had a chance to answer the prompt, > > compilation finished and obscured the prompt=20 See, now we're back to talking about the _prompt_, _not user input_ being obscured, right? The prompt is sent to the echo area. At least I think it is. I thought it was also logged in `*Messages*', but I don't see it there. Perhaps that happens only when the writing to the echo area uses an explicit call to `message'? In any case, I don't think it's in the minibuffer. If you have input in the minibuffer then it should still be there, after that prompting. I'm guessing that `y-or-n-p' is being used. That function calls `read-key', which calls `read-key-sequence-vector', a C function. Apparently the prompt doesn't get logged in `*Messages*' - I don't know why. > > with this message permanently: Compilation finished Yes, a subsequent message to the echo area can wipe out a message (in this case a prompt) that was there. I'd hope that both messages (the `y-or-n-p' prompt and the "Compilation finished" message) would be in `*Messages*', at least. Doesn't seem good, to me, that that doesn't seem to be the case. Not that it would be enough, to solve the problem described, just to log both messages in `*Messages*'. But at least that would mean that the prompt would not be permanently lost. It would anyway be lost from the echo area, however - yes. > > So I forgot about what was in the prompt :-( I agree that this is an unfortunate scenario. I don't want it to happen any more than you do. But what exactly is the recipe? How was it that you "requested files deletion that displayed the prompt" that you show? I'm using Emacs 26.3. `dired-do-flagged-delete' shows `Delete D [54 files] (yes or no)'. It sounds like you've maybe set `dired-deletion-confirmer' to `y-or-n-p'? (It's default value is `yes-or-no-p'.) If you had seen `(yes or no)' then you would be using the minibuffer. And if you had started to type, say, `ye' for `yes', then your minibuffer input would have been obscured only temporarily by the compilation message. And the prompt would not have been lost from the echo area by replacement by a subsequent message from the compilation process, because `yes-or-no-p' prompts in the minibuffer, not in the echo area. If you're using `y-or-n-p' then the problem has nothing at all to do with the minibuffer, AFAIK. Unlike `yes-or-no-p', which uses the minibuffer, `y-or-n-p' prompts using the echo area. And in that case the compilation message wipes out the `y-or-n-p' prompt. I would think that the first step toward a fix would be to make sure that the `y-or-n-p' prompt at least gets logged in `*Messages*'. (I thought it would be - I'm surprised.) But of course that doesn't solve the real problem. The problem, IIUC, is that messages to the echo area can wipe out earlier messages there. And `y-or-n-p', which uses the echo area for its "prompt", is (unfortunately, IMO) being used in your case for an important operation that destroys data (deletes files). The default is `yes-or-no-p' for `dired-deletion-confirmer' for a good reason. So what's the solution, for multiple writes to the echo area, including perhaps by async processes? Using the echo area for a "prompt" is, IMO, not a great idea. It's OK for some operations, but not for something delicate/critical. Users and code should not depend on a `y-or-n-p' interaction for something important. It's not just about writing a prompt to the echo area. The `y-or-n-p' - or any other `read-key' interaction, is hardly atomic, i.e., modal. `yes-or-no-p' and other minibuffer interactions aren't atomic either, but they really don't have the problem you raised. (And that's why I responded as I did. I thought you were talking about a use of the minibuffer and losing minibuffer input.) I made a suggestion in this thread, to present the `read-key' prompt, e.g. in the case where you use `y-or-n-p', not in the echo area (danger), but in a pop-up window: To read a key, the prompt basically _tells_ the the user to hit a key. It's not looking to read any input into a buffer - minibuffer or otherwise. Why not instead just put the prompt in a temporary (unselected) popup window or undecorated frame? And it's possible to use a modal dialog that keeps the prompt visible until you end/dismiss the dialog. One possibility is to add the prompt to the window that pops up to list the files to be deleted. IIUC, the general problem you present is this: 1. You are prompted in the echo area. 2. An async process writes a message to the echo area, wiping out the prompt from #1. That's to be avoided, first of all, IMO. That would be the first "fix" - don't do that. Maybe dialogs should never prompt in the echo area. Maybe they should instead open a window for the needed interaction, including the prompt. Maybe they should be modal in some cases. So what about use of the minibuffer as such a window for a dialog? For most uses it's fine. If it had been used in this case, e.g., if the default value of `dired-deletion-confirmer' (`yes-or-no-p') were used, then I don't think you would have had your problem. Yes, your minibuffer interaction would have been interrupted by the echo area, to show the compilation message. But the prompt and your partial input would have been restored after a brief delay, when the minibuffer was again shown in place of the echo area. I said "for most uses it's fine." That does not mean that the minibuffer is always the ideal way to realize a prompt-and-read-reply dialog. For something critical a modal dialog could be appropriate. What about the compilation-finished message? Maybe that shouldn't just plop down in the echo area. IOW, maybe there's some responsibility here for async operations that report status, to use another method - something that won't interfere with the echo area. There are no doubt other ways to try to deal with your problem. But I disagree with either of the following approaches. (It's still not clear to me whether you're trying to do either of these, but that's been my impression at some points of this discussion.) 1. Make `y-or-n-p' use the minibuffer. 2. Make `message' turn into `minibuffer-message' whenever the minibuffer is active. I've spoken to both of those. I don't want to bore you by repeating a lot, but if you want to talk more about those then I will. Summary about them (my opinion): 1. The minibuffer is generally not the place to read a single character or a key. It's a buffer for editing and entering multi-char input. `y-or-n-p' and other functions that use `read-key' and similar have good use cases, based on their advantages, i.e., on their specific behavior. They do not involve entering text and sending it by hitting RET. They're not associated with any particular window or buffer, with respect to the user input. The input action is to just hit a key. That's their advantage - and their disadvantage. And yes, they prompt in the echo area (AFAIK), which is not so great. We could consider letting them, alternatively, prompt somewhere else, such as in a popup. 2. During a minibuffer interaction (i.e., when the minibuffer is active) all kinds of things can go on. That includes recursive minibuffers, popping up and selecting other windows, using the echo area for temporal messages - anything at all, really. In particular, `message' can be useful when the minibuffer is active. So can `minibuffer-message'. Both are useful; neither replaces the other.=20 > > Since Drew doesn't want to improve safety > > to cover all such cases, Right; that's a fair thing to say, Juri. Drew doesn't want safety. Drew wants you to lose your data. Sheesh. Where do you get off saying such things? I spoke only to #1 and #2 above. Please do not make `y-or-n-p' read from the minibuffer, and please do not, when the minibuffer is active, force `message' to do what `minibuffer-message' does. I don't know if either is something you're trying to do, but both of those would be super misguided, IMO. And unnecessary. > > we need to address these issues one by one [...] >=20 > That's nearly impossible to do, and once you are done, > new cases will likely be introduced in the future. > Drew, how would you address this class of problems? See above. Hope it helps. I don't claim to have all the answers, and I might not understand the problem well. But I'm pretty sure that #1 and #2 above are not good. * Don't use `y-or-n-p' for something important. * Async operations should maybe not report simply by writing to the echo area, since: (1) it shares real estate with the minibuffer, and writing to it can interrupt a user interaction there; and=20 (2) it can overwrite other messages to the echo area (including from other async operations). * Maybe some important interactions should be modal, i.e., more or less blocking you from doing other things till the modal interaction is done; and maybe blocking reception of some async report messages. (They shouldn't block `C-g', though.) I'm not the one changing anything. If you leave the default value of `dired-deletion-confirmer' as `yes-or-no-p' then I don't think you'll have the problem you reported and are trying to fix. I'm not saying that there isn't a general potential problem, but I don't think it's where you said it is. I'm not the one changing anything. But those who are should maybe come up with suggestions - for general discussion. Why would this kind of thing be done in a bug thread (several bug threads?) but at the same time try to handle a general problem in a general way? Why wouldn't it instead be brought up at emacs-devel, where lots of informed people can speak to it? Emacs 27 isn't released yet. I have a recent snapshot now, but it doesn't show lots of things that have apparently been changed recently. It's frustrating to get a new Emacs release and find that lots of stuff that's always worked is broken because someone implemented what they thought was an improvement. Such things should generally be added as new, optional features, not just replace longstanding behavior. IMHO, the minibuffer ain't broke, and likewise `message' and the echo area. Can there be bad use cases, problems that we can identify? Sure. But let's not throw out the baby with the bath water. Before changing something like `y-or-n-p' or `message' (again, I'm not sure that's what you're doing - not clear to me), why not bring it up for general discussion? From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2019 05:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15739699753918 (code B ref 17272); Sun, 17 Nov 2019 05:53:01 +0000 Received: (at 17272) by debbugs.gnu.org; 17 Nov 2019 05:52:55 +0000 Received: from localhost ([127.0.0.1]:39968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWDUV-000117-EE for submit@debbugs.gnu.org; Sun, 17 Nov 2019 00:52:55 -0500 Received: from quimby.gnus.org ([95.216.78.240]:42166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWDUT-00010q-Hf; Sun, 17 Nov 2019 00:52:53 -0500 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iWDUL-0003i9-9m; Sun, 17 Nov 2019 06:52:47 +0100 From: Lars Ingebrigtsen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> Date: Sun, 17 Nov 2019 06:52:44 +0100 In-Reply-To: <87lfsfmtk0.fsf@mail.linkov.net> (Juri Linkov's message of "Sat, 16 Nov 2019 22:53:51 +0200") Message-ID: <875zjjgic3.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > But before I had a chance to answer the prompt, compilation finished > and obscured the prompt with this message permanently: > > Compilation finished > > So I forgot about what was in the prompt :- [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linkov.net] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Juri Linkov writes: > But before I had a chance to answer the prompt, compilation finished > and obscured the prompt with this message permanently: > > Compilation finished > > So I forgot about what was in the prompt :-( Yeah, it's a problem all over the place. > Since Drew doesn't want to improve safety to cover all such cases, > we need to address these issues one by one, so here is the next patch: Drew doesn't have very powers. I say go ahead and make the change in `message' (with a variable that can be used to force `message' to not behave like `minibuffer-message'). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2019 05:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15739699853981 (code B ref 17272); Sun, 17 Nov 2019 05:54:01 +0000 Received: (at 17272) by debbugs.gnu.org; 17 Nov 2019 05:53:05 +0000 Received: from localhost ([127.0.0.1]:39975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWDUf-000128-4c for submit@debbugs.gnu.org; Sun, 17 Nov 2019 00:53:05 -0500 Received: from quimby.gnus.org ([95.216.78.240]:42184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWDUb-00011M-RB; Sun, 17 Nov 2019 00:53:02 -0500 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iWDUU-0003iI-0D; Sun, 17 Nov 2019 06:52:56 +0100 From: Lars Ingebrigtsen In-Reply-To: <87lfsfmtk0.fsf@mail.linkov.net> (Juri Linkov's message of "Sat, 16 Nov 2019 22:53:51 +0200") References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Date: Sun, 17 Nov 2019 06:52:53 +0100 Message-ID: <874kz3gibu.fsf@gnus.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > But before I had a chance to answer the prompt, compilation finished > and obscured the prompt with this message permanently: > > Compilation finished > > So I forgot about what was in the prompt :- [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ingebrigtsen.no] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Juri Linkov writes: > But before I had a chance to answer the prompt, compilation finished > and obscured the prompt with this message permanently: > > Compilation finished > > So I forgot about what was in the prompt :-( Yeah, it's a problem all over the place. > Since Drew doesn't want to improve safety to cover all such cases, > we need to address these issues one by one, so here is the next patch: Drew doesn't have veto powers. I say go ahead and make the change in `message' (with a variable that can be used to force `message' to not behave like `minibuffer-message'). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2019 22:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Drew Adams Cc: Michael Heerdegen , Lars Ingebrigtsen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157402869420548 (code B ref 17272); Sun, 17 Nov 2019 22:12:02 +0000 Received: (at 17272) by debbugs.gnu.org; 17 Nov 2019 22:11:34 +0000 Received: from localhost ([127.0.0.1]:42866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWSla-0005LL-EF for submit@debbugs.gnu.org; Sun, 17 Nov 2019 17:11:34 -0500 Received: from buffalo.birch.relay.mailchannels.net ([23.83.209.24]:36740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWSlY-0005L9-4g; Sun, 17 Nov 2019 17:11:33 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D445250137B; Sun, 17 Nov 2019 22:11:30 +0000 (UTC) Received: from pdx1-sub0-mail-a52.g.dreamhost.com (100-96-4-107.trex.outbound.svc.cluster.local [100.96.4.107]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 50C3D5014A4; Sun, 17 Nov 2019 22:11:30 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a52.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sun, 17 Nov 2019 22:11:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Bored-Average: 6db373b04d4e7315_1574028690572_156919188 X-MC-Loop-Signature: 1574028690572:2614130984 X-MC-Ingress-Time: 1574028690572 Received: from pdx1-sub0-mail-a52.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a52.g.dreamhost.com (Postfix) with ESMTP id ECF7881897; Sun, 17 Nov 2019 14:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=Ikmsyr6Z+P23PBHi7puVZg91Eyg=; b= XGWsrTlTwkQUThnoKW+mGf/WmyHg7cCchePPPDJ48tgjfEuVbnHZTvI9o3o0qEAT 47NS2VpZkqvArglQkoVFrW2N6j9HK2dXR9edetg1NFh87qJ5FvrIE4MCQo6WFHlS eGXNDrM1FYUW/MXAi+eHDXRlgmsICawpMcRsxUFUSoU= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a52.g.dreamhost.com (Postfix) with ESMTPSA id E2C958189E; Sun, 17 Nov 2019 14:11:21 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a52 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <87v9rjv45e.fsf@web.de> <266012df-8baf-469d-83b0-25f9cfdff603@default> Date: Sun, 17 Nov 2019 23:58:10 +0200 In-Reply-To: <266012df-8baf-469d-83b0-25f9cfdff603@default> (Drew Adams's message of "Sat, 16 Nov 2019 17:42:06 -0800 (PST)") Message-ID: <87lfsew4ek.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > So you're saying it wasn't a mistake for you to say > that _user input_ (not a prompt) is permanently > hidden? The minibuffer is composed of both the prompt and user input. Both the prompt and user input are hidden permanently by the message covering the whole minibuffer. > If you had seen `(yes or no)' then you would be > using the minibuffer. And if you had started to > type, say, `ye' for `yes', then your minibuffer > input would have been obscured only temporarily by > the compilation message. Not temporarily, but permanently. > Using the echo area for a "prompt" is, IMO, not a > great idea. I agree, this is why using the minibuffer is better. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2019 22:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Drew Adams , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157402870220579 (code B ref 17272); Sun, 17 Nov 2019 22:12:02 +0000 Received: (at 17272) by debbugs.gnu.org; 17 Nov 2019 22:11:42 +0000 Received: from localhost ([127.0.0.1]:42871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWSli-0005Lp-0m for submit@debbugs.gnu.org; Sun, 17 Nov 2019 17:11:42 -0500 Received: from butterfly.birch.relay.mailchannels.net ([23.83.209.27]:52776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWSlf-0005Le-SQ; Sun, 17 Nov 2019 17:11:40 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BD3EF600669; Sun, 17 Nov 2019 22:11:38 +0000 (UTC) Received: from pdx1-sub0-mail-a52.g.dreamhost.com (100-96-6-199.trex.outbound.svc.cluster.local [100.96.6.199]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3F5BB60060B; Sun, 17 Nov 2019 22:11:38 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a52.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sun, 17 Nov 2019 22:11:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Wide-Eyed-Turn: 38ad60dc32b990f3_1574028698506_2520877986 X-MC-Loop-Signature: 1574028698506:116528159 X-MC-Ingress-Time: 1574028698505 Received: from pdx1-sub0-mail-a52.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a52.g.dreamhost.com (Postfix) with ESMTP id 757BA8189F; Sun, 17 Nov 2019 14:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=Jp9JZnxo6PrQUEbuBrNfgS6adWM=; b= T+XudVTrVIwlfMAeIAyji/lO7oiX/ItDPuegYU2PxwfP0+Vi+iVU247zOLYEHjfO AS1HN7Dy+z9xLAPWNvXtCQMEGpDywkQ7mTI2TlnK7Oyq14Ip/+Yeoi2QXSaiowBR 3R31TDixBiXV9l0lmggSdXR/yebNlB4mhRCgPfygI8c= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a52.g.dreamhost.com (Postfix) with ESMTPSA id 68C09817CE; Sun, 17 Nov 2019 14:11:29 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a52 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> Date: Sun, 17 Nov 2019 23:59:50 +0200 In-Reply-To: <874kz3gibu.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sun, 17 Nov 2019 06:52:53 +0100") Message-ID: <87bltaw3xz.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> But before I had a chance to answer the prompt, compilation finished >> and obscured the prompt with this message permanently: >> >> Compilation finished >> >> So I forgot about what was in the prompt :-( > > Yeah, it's a problem all over the place. > >> Since Drew doesn't want to improve safety to cover all such cases, >> we need to address these issues one by one, so here is the next patch: > > Drew doesn't have veto powers. I say go ahead and make the change in > `message' (with a variable that can be used to force `message' to not > behave like `minibuffer-message'). Yes, I believe a new variable would make Drew happy. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2019 23:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , Lars Ingebrigtsen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157403488730502 (code B ref 17272); Sun, 17 Nov 2019 23:55:02 +0000 Received: (at 17272) by debbugs.gnu.org; 17 Nov 2019 23:54:47 +0000 Received: from localhost ([127.0.0.1]:42935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWUNP-0007vl-9B for submit@debbugs.gnu.org; Sun, 17 Nov 2019 18:54:47 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:57958) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWUNK-0007vK-IT; Sun, 17 Nov 2019 18:54:41 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAHNsVR1081533; Sun, 17 Nov 2019 23:54:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=Z4t/anZxgsJn4k+zRGOVnOJKkaDeKfi8Z2R0sAN6lp0=; b=Z63nFzOYhbPMClYx2trWQVSxE3+Rs/SRuJmVPe6x6xZyEIheS9vPbs/CU36tvut1tugU OvKAGxsRQ0s7L8uh4Lb39L2rdxJUaFMlQ9TcnKl7EVJw0Ktc4TXdx/S/HM/TdouaDYys 3N7ON9tiZaeyLAtZIKU5Sj/6qtl4SsdPLCf7m8kJfebLXmF2kzgm7cHOATB0dC4u9oWG 0SJYFxqaZb2UG0vlGOqNl5d+Lp4imeJ4NWgOheSXeOMuXdYzZYpe5Z2JQCvpo5/VfSi5 Kh9oLO3EWc3sZGxJAHfXgHMYa7KMIQEGKB5D7uoMjBB5CkX1Oy4lUgDKATMMbobPBZB4 Og== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2wa9rq4hyp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 17 Nov 2019 23:54:31 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAHNsR3f053351; Sun, 17 Nov 2019 23:54:30 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2wau93j916-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 17 Nov 2019 23:54:30 +0000 Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAHNsL7F004853; Sun, 17 Nov 2019 23:54:27 GMT MIME-Version: 1.0 Message-ID: <4ffe34ef-019e-49bf-b2b0-76ee9ce88fcf@default> Date: Sun, 17 Nov 2019 15:54:20 -0800 (PST) From: Drew Adams References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <87v9rjv45e.fsf@web.de> <266012df-8baf-469d-83b0-25f9cfdff603@default> <87lfsew4ek.fsf@mail.linkov.net> In-Reply-To: <87lfsew4ek.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4927.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9444 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911170229 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9444 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911170229 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > So you're saying it wasn't a mistake for you to say > > that _user input_ (not a prompt) is permanently > > hidden? >=20 > The minibuffer is composed of both the prompt and user input. > Both the prompt and user input are hidden permanently > by the message covering the whole minibuffer. It was about `y-or-n-p', which, I repeat, does NOT use the minibuffer. It prompts in the echo area, and it calls `read-key', which does not read textual input from anywhere - certainly not the minibuffer. You are doubling down, but you haven't yet provided any recipe that shows that user input gets hidden permanently. The only thing you've shown is that an echo-area prompt can be overwritten, and so be lost, by subsequent echo-area output (such as from `message'). And that's just what the original bug reports reported in the first place! Still, you repeat that user input is permanently hidden. Please show how. > > If you had seen `(yes or no)' then you would be > > using the minibuffer. And if you had started to > > type, say, `ye' for `yes', then your minibuffer > > input would have been obscured only temporarily by > > the compilation message. >=20 > Not temporarily, but permanently. Not when I follow your recipe. And not even if I redefine `dired-deletion-confirmer' as `y-or-n-p'. I guess you've indirectly confirmed that you did redefine `dired-deletion-confirmer' as `y-or-n-p'? Otherwise, how is it that you saw `(y or n)' and not `(yes or no)'? But if you did that then the `y-or-n-p' prompt would be sent to the echo area; it would not be used in the minibuffer. The minibuffer wouldn't be involved in your recipe at all. On the other hand, you now seem to be indirectly saying that you did see `(yes or no)'. Is that it? Just what is your recipe? Please start from, say, `emacs -Q' with, say, Emacs 26.3. Writing to the echo area does not affect minibuffer input. And it does not exit the minibuffer. It obscures minibuffer input _temporarily_, until you hit a key, for example. AFAIK, this is just a fact. I know of no possibility that allows writing to the echo area to lose your minibuffer input or hide it permanently. For a write to the echo area to do that, the echo area would need to permanently hide the minibuffer. I don't see that happening. So no, I disagree with a claim that minibuffer input is permanently hidden. Until you can show a recipe to reproduce that. > > Using the echo area for a "prompt" is, IMO, not a > > great idea. >=20 > I agree, this is why using the minibuffer is better. Yes. But only when it makes sense to use the minibuffer. That's generally not the case for reading a single char or a key sequence. We have `read-char' and `read-key' for a reason. The minibuffer is not the best UI for every interaction. (And that's coming from someone who uses the minibuffer for more than most people do.) Is your plan to make `read-key' and such use the minibuffer? I _really_ hope not. And I hope you won't do that to `y-or-n-p'. As I acknowledged - and as I reported originally in bug #19064, there _is_ a problem with prompting in the echo area, which is what `y-or-n-p' does (likewise, other functions that call things like `read-key'). I mentioned some possible remedies for that in my previous mail (and before that). And I mentioned a different remedy in my original report for #19064. And the remedy I suggested in the #19064 report was apparently the same one given by the OP of #17272. We both suggested, independently, that `message' be made to hold off, if some dialog is in progress that uses the echo area for a prompt and that reads a char/key. And Michael suggested another approach, also reasonable. Just what the right fix is for those two merged bugs can be discussed. But neither involves the minibuffer. And neither should be "fixed" by making it involve the minibuffer. And AFAICT, any discussion of the minibuffer in the context of these two bugs is just a distraction or obfuscation. The problem is this: losing an echo-area prompt by `y-or-n-p' because of a subsequent write to the echo area, in particular by `message'. The problem reported by these two bugs has nothing whatsoever to do with the minibuffer, AFAIK. Why you introduced the minibuffer into this, I don't know. If there's another bug, which involves the minibuffer (e.g., input loss or permanent hiding in some way), then maybe file a bug report for that? This bug - these 2 merged bugs, are not about the minibuffer. Or if you really think they are, please explain how. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Nov 2019 21:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157411390620152 (code B ref 17272); Mon, 18 Nov 2019 21:52:02 +0000 Received: (at 17272) by debbugs.gnu.org; 18 Nov 2019 21:51:46 +0000 Received: from localhost ([127.0.0.1]:46355 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWovx-0005Ex-Mp for submit@debbugs.gnu.org; Mon, 18 Nov 2019 16:51:46 -0500 Received: from chocolate.birch.relay.mailchannels.net ([23.83.209.35]:38073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWovu-0005El-Vp; Mon, 18 Nov 2019 16:51:44 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8578E3C035E; Mon, 18 Nov 2019 21:51:41 +0000 (UTC) Received: from pdx1-sub0-mail-a6.g.dreamhost.com (100-96-196-51.trex.outbound.svc.cluster.local [100.96.196.51]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EC6A93C0172; Mon, 18 Nov 2019 21:51:40 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a6.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Mon, 18 Nov 2019 21:51:41 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Language-Society: 62bd5ac44c3f81fb_1574113901275_2416894597 X-MC-Loop-Signature: 1574113901275:139463986 X-MC-Ingress-Time: 1574113901274 Received: from pdx1-sub0-mail-a6.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a6.g.dreamhost.com (Postfix) with ESMTP id 2B1EBA7011; Mon, 18 Nov 2019 13:51:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=45WSH53PNh3bzdPF7JdsHaK+91c=; b= p4lohBMJ9yZmNwXQ48vO49Gevdj1Obwa4F1oyHRCuc0jB8K2JR8ShhbVKtSORj/P 3Kc8XEvO7DFMDHQMQixIzFyDSZV5lZLFx97yw6/ioJw+UabM4v8dphifMD3KC/Mk WMTJ6xvsqlw7pEz08RnsFotrIUSEkgDMtO3CN1ebxys= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 33048A7004; Mon, 18 Nov 2019 13:51:34 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a6 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87r3i9nped.fsf@gnus.org> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> Date: Mon, 18 Nov 2019 23:10:30 +0200 In-Reply-To: <87bltaw3xz.fsf@mail.linkov.net> (Juri Linkov's message of "Sun, 17 Nov 2019 23:59:50 +0200") Message-ID: <87r224x54p.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >>> But before I had a chance to answer the prompt, compilation finished >>> and obscured the prompt with this message permanently: >>> >>> Compilation finished >>> >>> So I forgot about what was in the prompt :-( >> >> Yeah, it's a problem all over the place. >> >>> Since Drew doesn't want to improve safety to cover all such cases, >>> we need to address these issues one by one, so here is the next patch= : >> >> Drew doesn't have veto powers. I say go ahead and make the change in >> `message' (with a variable that can be used to force `message' to not >> behave like `minibuffer-message'). > > Yes, I believe a new variable would make Drew happy. The variable name is =E2=80=98message-in-echo-area=E2=80=99. After a lit= tle testing, it seems to handle all such cases well: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=message-in-echo-area.patch diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 6e72eb73f9..7e74fa1ffb 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -712,16 +712,16 @@ minibuffer-message (progn (if args (apply #'message message args) - (message "%s" message)) + (message-in-echo-area "%s" message)) (prog1 (sit-for (or minibuffer-message-timeout 1000000)) - (message nil))) + (message-in-echo-area nil))) ;; Record message in the *Messages* buffer (let ((inhibit-message t)) (if args (apply #'message message args) - (message "%s" message))) + (message-in-echo-area "%s" message))) ;; Clear out any old echo-area message to make way for our new thing. - (message nil) + (message-in-echo-area nil) (setq message (if (and (null args) (string-match-p "\\` *\\[.+\\]\\'" message)) ;; Make sure we can put-text-property. diff --git a/src/editfns.c b/src/editfns.c index 8fc866d391..a1e3fb1fa5 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -2877,6 +2877,49 @@ Fmessage usage: (message FORMAT-STRING &rest ARGS) */) (ptrdiff_t nargs, Lisp_Object *args) +{ + if (NILP (Vmessage_in_echo_area) + && !(NILP (args[0]) || (STRINGP (args[0]) && SBYTES (args[0]) == 0)) + && WINDOW_LIVE_P (Fold_selected_window ()) + && BUFFERP (Fwindow_buffer (Fold_selected_window ())) + && !NILP (Fminibufferp (Fwindow_buffer (Fold_selected_window ())))) + { + ptrdiff_t count = SPECPDL_INDEX (); + + /* Avoid possible recursion. */ + specbind (Qmessage_in_echo_area, Qt); + + record_unwind_current_buffer (); + Fset_buffer (Fwindow_buffer (Fold_selected_window ())); + + return unbind_to (count, CALLN (Fapply, intern ("minibuffer-message"), + Flist (nargs, args))); + } + else + return Fmessage_in_echo_area (nargs, args); +} + +DEFUN ("message-in-echo-area", Fmessage_in_echo_area, Smessage_in_echo_area, 1, MANY, 0, + doc: /* Display a message at the bottom of the screen. +The message also goes into the `*Messages*' buffer, if `message-log-max' +is non-nil. (In keyboard macros, that's all it does.) +Return the message. + +In batch mode, the message is printed to the standard error stream, +followed by a newline. + +The first argument is a format control string, and the rest are data +to be formatted under control of the string. Percent sign (%), grave +accent (\\=`) and apostrophe (\\=') are special in the format; see +`format-message' for details. To display STRING without special +treatment, use (message-in-echo-area "%s" STRING). + +If the first argument is nil or the empty string, the function clears +any existing message; this lets the minibuffer contents show. See +also `current-message'. + +usage: (message-in-echo-area FORMAT-STRING &rest ARGS) */) + (ptrdiff_t nargs, Lisp_Object *args) { if (NILP (args[0]) || (STRINGP (args[0]) @@ -4520,6 +4563,11 @@ syms_of_editfns (void) it to be non-nil. */); binary_as_unsigned = false; + DEFVAR_LISP ("message-in-echo-area", Vmessage_in_echo_area, + doc: /* Non-nil means overwrite the minibuffer with a message in the echo area. */); + Vmessage_in_echo_area = Qnil; + DEFSYM (Qmessage_in_echo_area, "message-in-echo-area"); + defsubr (&Spropertize); defsubr (&Schar_equal); defsubr (&Sgoto_char); @@ -4594,6 +4642,7 @@ syms_of_editfns (void) defsubr (&Semacs_pid); defsubr (&Ssystem_name); defsubr (&Smessage); + defsubr (&Smessage_in_echo_area); defsubr (&Smessage_box); defsubr (&Smessage_or_box); defsubr (&Scurrent_message); --=-=-=-- From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Nov 2019 08:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157415123512536 (code B ref 17272); Tue, 19 Nov 2019 08:14:02 +0000 Received: (at 17272) by debbugs.gnu.org; 19 Nov 2019 08:13:55 +0000 Received: from localhost ([127.0.0.1]:46543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWye2-0003G3-NK for submit@debbugs.gnu.org; Tue, 19 Nov 2019 03:13:54 -0500 Received: from quimby.gnus.org ([95.216.78.240]:49090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWye0-0003Fk-1u; Tue, 19 Nov 2019 03:13:52 -0500 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iWyds-0002iF-6X; Tue, 19 Nov 2019 09:13:46 +0100 From: Lars Ingebrigtsen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> Date: Tue, 19 Nov 2019 09:13:43 +0100 In-Reply-To: <87r224x54p.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 18 Nov 2019 23:10:30 +0200") Message-ID: <87v9rgnv0o.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > The variable name is =?UTF-8?Q?=E2=80=98message-in-echo-area=E2=80=99.?= After a little testing, > it seems to handle all such cases well: I have not tested the patch, but it looks good to me. Tiny comment: Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ingebrigtsen.no] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Juri Linkov writes: > The variable name is =E2=80=98message-in-echo-area=E2=80=99. After a lit= tle testing, > it seems to handle all such cases well: I have not tested the patch, but it looks good to me. Tiny comment: > usage: (message FORMAT-STRING &rest ARGS) */) > (ptrdiff_t nargs, Lisp_Object *args) > +{ > + if (NILP (Vmessage_in_echo_area) The doc string of `message' (and documentation) should mention this variable, and this should also be mentioned in NEWS. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Nov 2019 11:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Lars Ingebrigtsen , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157416191412826 (code B ref 17272); Tue, 19 Nov 2019 11:12:02 +0000 Received: (at 17272) by debbugs.gnu.org; 19 Nov 2019 11:11:54 +0000 Received: from localhost ([127.0.0.1]:46674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iX1QI-0003Kn-6o for submit@debbugs.gnu.org; Tue, 19 Nov 2019 06:11:54 -0500 Received: from mail-il1-f178.google.com ([209.85.166.178]:34531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iX1QG-0003KM-GV; Tue, 19 Nov 2019 06:11:52 -0500 Received: by mail-il1-f178.google.com with SMTP id p6so19277071ilp.1; Tue, 19 Nov 2019 03:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v5f+4RoW5+DsQLt2L2s4loRQpdPzjh3yIvIlXaw3uJM=; b=XOLtPXEt8xlw40soD7DNe734mOF/AUF+Jv+a02uxWzH/1oanBXuYi6mRrwc7RYkwkv DyQaKmZOBE5Csl6JXYVgsBNLkqLFqL7ucpug42HCqNNUhJ6o0rnceQaRsy3xKD/8KAdw 3fsJNxdLKRbGh7BEvlY72ZZCcj/FVJdjRYE6QbsVWb8h3qsQ7hYoCrZ6SynkOiLbCb/P bYxaSghRQHAosZC4nWNUgj4Hp1zc6cRqtJoQ0UTbWbGdyAbm9zS1nb2lH4IChvFyE4Iv 6J3jT9ZiWmF6bFnjchswAsgCBmS3b0CNCPmZbXl914dlZXjosMBYSgLhpUN170AJdvJ4 KFMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v5f+4RoW5+DsQLt2L2s4loRQpdPzjh3yIvIlXaw3uJM=; b=maK2zPzDRrajf+kBX2CUVd63UYjXzQicvpBTHCvH8616yfPCu3WMND3QvNlH6moJx1 VUis6vJYQq3PV6lupjJfoXrdQlz7Q4FtEIdBdHufDsvOKpQ8mUmUCchWch15CwRsjTfF 0UciBwNyxlRaFwTE3193FGrhKUiDVKCtWlWLigdgxOFrx5IjFeYSF8zAR26LvcIocWYI ZqD2noJHPnKt8RYH+sJUUZ1FG0NBfNQucGLVbM6u87NhpjcJX35yUm5e9YXysajSUbtJ 6rNOavT8vnTYK2hextPQeAyHW0NjbCPR+KWdI7anL61xDrP1Lf4+wSSNWVBsxXoHiUbN Exmg== X-Gm-Message-State: APjAAAUKc/XOZkBKUsraBrBPLr0XnQD9NA5SddySx+TCJgFnoyZCz4wd 2nmpFMO15bgJufXDjtF31fXMH12Qgjnl8GA7xfI= X-Google-Smtp-Source: APXvYqwGbvQRC6CAmHGqv5yi439zslouYR+b7GF4gEoUjWWLu0kAkbwmZGrOPBh5dMP2y21VVgjtimQR+j95qHI6ldU= X-Received: by 2002:a92:1513:: with SMTP id v19mr20864182ilk.125.1574161906926; Tue, 19 Nov 2019 03:11:46 -0800 (PST) MIME-Version: 1.0 References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> In-Reply-To: <87v9rgnv0o.fsf@gnus.org> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Tue, 19 Nov 2019 11:11:35 +0000 Message-ID: Content-Type: multipart/alternative; boundary="000000000000480a030597b121f9" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000480a030597b121f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, I can't confirm 100% if this is the right bug to report this to, but the recent changes by Juri, which make yes-or-no-p use the minibuffer for reading, break fido-mode's icomplete-magic-kill command (apologies if that's not the exact name). That command prompts the user for confirmation before attempting a file deletion or buffer kill. This is done inside the minibuffer. I haven't followed the whole discussion so I don't know if you're aware of this problem. Either way, is there an alternative for modes such as fido-mode? Thanks, Jo=C3=A3o On Tue, Nov 19, 2019, 08:14 Lars Ingebrigtsen wrote: > Juri Linkov writes: > > > The variable name is =E2=80=98message-in-echo-area=E2=80=99. After a l= ittle testing, > > it seems to handle all such cases well: > > I have not tested the patch, but it looks good to me. Tiny comment: > > > usage: (message FORMAT-STRING &rest ARGS) */) > > (ptrdiff_t nargs, Lisp_Object *args) > > +{ > > + if (NILP (Vmessage_in_echo_area) > > The doc string of `message' (and documentation) should mention this > variable, and this should also be mentioned in NEWS. > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > > > > --000000000000480a030597b121f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

I can't confirm 100% if this is the right bug to report this to, bu= t the recent changes by Juri, which make yes-or-no-p use the minibuffer for= reading,=C2=A0 break fido-mode's icomplete-magic-kill command (apologi= es if that's not the exact name).

That command prompts the user for confirmation before attempt= ing a file deletion or buffer kill. This is done inside the minibuffer.

I haven't followed the = whole discussion so I don't know if you're aware of this problem. E= ither way, is there an alternative for modes such as fido-mode?

Thanks,
Jo= =C3=A3o

On Tue, Nov 19, 2019, 08:14 Lars Ingebrigtsen <larsi@gnus.org> wrote:
Juri Linkov <juri@linkov.net> writes:

> The variable name is =E2=80=98message-in-echo-area=E2=80=99.=C2=A0 Aft= er a little testing,
> it seems to handle all such cases well:

I have not tested the patch, but it looks good to me.=C2=A0 Tiny comment:
>=C2=A0 usage: (message FORMAT-STRING &rest ARGS)=C2=A0 */)
>=C2=A0 =C2=A0 (ptrdiff_t nargs, Lisp_Object *args)
> +{
> +=C2=A0 if (NILP (Vmessage_in_echo_area)

The doc string of `message' (and documentation) should mention this
variable, and this should also be mentioned in NEWS.

--
(domestic pets only, the antidote for overdose, milk.)
=C2=A0 =C2=A0bloggy blog: http://lars.ingebrigtsen.no



--000000000000480a030597b121f9-- From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Nov 2019 23:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157420562817015 (code B ref 17272); Tue, 19 Nov 2019 23:21:02 +0000 Received: (at 17272) by debbugs.gnu.org; 19 Nov 2019 23:20:28 +0000 Received: from localhost ([127.0.0.1]:48698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXCnL-0004QM-PF for submit@debbugs.gnu.org; Tue, 19 Nov 2019 18:20:28 -0500 Received: from bumble.birch.relay.mailchannels.net ([23.83.209.25]:21681) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXCnI-0004Q6-Bo; Tue, 19 Nov 2019 18:20:26 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5BCAA8C159A; Tue, 19 Nov 2019 23:20:23 +0000 (UTC) Received: from pdx1-sub0-mail-a94.g.dreamhost.com (100-96-83-20.trex.outbound.svc.cluster.local [100.96.83.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C757B8C1737; Tue, 19 Nov 2019 23:20:22 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a94.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 19 Nov 2019 23:20:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Irritate-Scare: 5a1d582856c978d7_1574205623160_3245983446 X-MC-Loop-Signature: 1574205623160:193071215 X-MC-Ingress-Time: 1574205623160 Received: from pdx1-sub0-mail-a94.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTP id 93AE47FC55; Tue, 19 Nov 2019 15:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=L+pTGz lPWzlV+h06fUWN454uTjk=; b=B70/UJj6LlpLwYWEXtCDQZ6dhXCTj7K6NAMLMY bOMFGc17fMan8axJAMFY4PufVIimPQSifa7LYAuKVZN7XWDN5UBN9e7cBd6SN0mL ijwlz8J4zu3ua0VMj+QOgjKAO4ooRiaDpRCcDMIRD4cQuLhpe0VDICLYnzaAhhH8 qdx8E= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTPSA id 107E27FC58; Tue, 19 Nov 2019 15:20:16 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a94 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87wps1m7co.fsf@web.de> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> Date: Wed, 20 Nov 2019 00:28:15 +0200 In-Reply-To: <87v9rgnv0o.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 19 Nov 2019 09:13:43 +0100") Message-ID: <878sobqxb4.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> The variable name is =E2=80=98message-in-echo-area=E2=80=99. After a = little testing, >> it seems to handle all such cases well: > > I have not tested the patch, but it looks good to me. Actually this patch needs more testing. I found already two cases that might be annoying. Better to anticipate a possible angry reaction and fix these cases in advance. The first case is when doing completion, the message "Making completion list..." is displayed in the minibuffer for 2 seconds. I don't understand why this message is needed at all, but at least this patch restores its previous behavior that displays that message in the echo area and doesn't wait. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 6e72eb73f9..b3fc3b8ab0 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -1838,7 +1838,7 @@ completion--done (defun minibuffer-completion-help (&optional start end) "Display a list of possible completions of the current minibuffer cont= ents." (interactive) - (message "Making completion list...") + (message-in-echo-area "Making completion list...") (let* ((start (or start (minibuffer-prompt-end))) (end (or end (point-max))) (string (buffer-substring start end)) @@ -1849,7 +1849,7 @@ minibuffer-completion-help minibuffer-completion-predicate (- (point) start) md))) - (message nil) + (message-in-echo-area nil) (if (or (null completions) (and (not (consp (cdr completions))) (equal (car completions) string))) Another case when using isearch in minibuffer, the failed search message is displayed at the end of the minibuffer instead of in the search prompt in the echo area. This patch restores the previous behavior: diff --git a/lisp/isearch.el b/lisp/isearch.el index 4f3342782d..1705b050b5 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -2011,7 +2011,7 @@ isearch-message-properties (defun isearch--momentary-message (string) "Print STRING at the end of the isearch prompt for 1 second." (let ((message-log-max nil)) - (message "%s%s%s" + (message-in-echo-area "%s%s%s" (isearch-message-prefix nil isearch-nonincremental) isearch-message (apply #'propertize (format " [%s]" string) @@ -3168,7 +3170,7 @@ isearch-message (isearch-message-prefix ellipsis isearch-nonincremental) m (isearch-message-suffix c-q-hack))) - (if c-q-hack m (let ((message-log-max nil)) (message "%s" m))))) + (if c-q-hack m (let ((message-log-max nil)) (message-in-echo-area "%= s" m))))) =20 (defun isearch--describe-regexp-mode (regexp-function &optional space-be= fore) "Make a string for describing REGEXP-FUNCTION. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Nov 2019 23:21:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Lars Ingebrigtsen , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157420563917051 (code B ref 17272); Tue, 19 Nov 2019 23:21:03 +0000 Received: (at 17272) by debbugs.gnu.org; 19 Nov 2019 23:20:39 +0000 Received: from localhost ([127.0.0.1]:48703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXCnW-0004Qu-1T for submit@debbugs.gnu.org; Tue, 19 Nov 2019 18:20:38 -0500 Received: from bonobo.elm.relay.mailchannels.net ([23.83.212.22]:41727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXCnO-0004QY-HA; Tue, 19 Nov 2019 18:20:31 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3A9D7E11A7; Tue, 19 Nov 2019 23:20:29 +0000 (UTC) Received: from pdx1-sub0-mail-a94.g.dreamhost.com (100-96-83-20.trex.outbound.svc.cluster.local [100.96.83.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B3EBBE112F; Tue, 19 Nov 2019 23:20:28 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a94.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 19 Nov 2019 23:20:29 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Interest-Soft: 7b25d9746017e1c5_1574205629028_482425806 X-MC-Loop-Signature: 1574205629027:3774749358 X-MC-Ingress-Time: 1574205629027 Received: from pdx1-sub0-mail-a94.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTP id 151C57FC58; Tue, 19 Nov 2019 15:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=c0A472k+KHEtT5R0f9CejP5UU6A=; b= fM/ujVoBI/U3Ze9ftzHJmvQ0LE91yJMB9CPJsuGm6oWLQubVNDZPMgFSY4kwhQ2b QWolyKXgpCxzDHeEegMQa8IlNrNyiMMYVMthh/V0JBY0lPvZxozlIde86Uwm/DZm +Rk3IVLuoTdzTkwnw+dwLllDoUF3RkxOG7GmclfXRNQ= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTPSA id 190D47FC59; Tue, 19 Nov 2019 15:20:24 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a94 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> Date: Wed, 20 Nov 2019 00:39:04 +0200 In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 19 Nov 2019 11:11:35 +0000") Message-ID: <877e3vqx9r.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > I can't confirm 100% if this is the right bug to report this to, but > the recent changes by Juri, which make yes-or-no-p use the minibuffer > for reading, break fido-mode's icomplete-magic-kill command > (apologies if that's not the exact name). Please provide step-by-step recipe, it's hard to see what is wrong. I tried everything, and don't see anything unusual. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Nov 2019 23:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Lars Ingebrigtsen , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157420672119105 (code B ref 17272); Tue, 19 Nov 2019 23:39:01 +0000 Received: (at 17272) by debbugs.gnu.org; 19 Nov 2019 23:38:41 +0000 Received: from localhost ([127.0.0.1]:48731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXD4y-0004y2-VJ for submit@debbugs.gnu.org; Tue, 19 Nov 2019 18:38:41 -0500 Received: from mail-il1-f172.google.com ([209.85.166.172]:42418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXD4v-0004xi-IN; Tue, 19 Nov 2019 18:38:39 -0500 Received: by mail-il1-f172.google.com with SMTP id n18so273534ilt.9; Tue, 19 Nov 2019 15:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=51z1xrtrB2UI6g+gjGP+WUWcQbofg1MATSJm9ZHHVRI=; b=E0y/fIHXULuh38JOilOr4ujnvRyXdeVN0wpellSVZUAWIMSywREeGKXU1juRMR9V3k KN3y/dwoUbbEar8scEaODrh0JFd7VEo0R6/yoIrTaGeyGQ5kBZjcf82tOqhgKyNPtU+0 5rFc2u7ND2vmD7rl+Zvt4JykwPbeGvjk3XpJBN1mBMHGKomLmNsPyJCTnH//D3abp8nZ bmqlubT01l+231us/eBZvP4P34ACN3vNOGfb8N7EFhALz/KunW1+epELZgdOvFgJR5Nr E1HtZ+v9/GmpgH/5ba2r0tjHeDHV0CtPiWtTwtLK5MxsyjSENyMvYM3Lzth50SUSR69W K/Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=51z1xrtrB2UI6g+gjGP+WUWcQbofg1MATSJm9ZHHVRI=; b=CBZBSzmlF0P8RZd335Cp9bqoy8wgZIfR9oNOCLvA1ceRmivRO+qUG+eAj8Mm2q1HLL 3EQNLbRUFZU934a1YkzRYjW82AHZl+vlWiTG8mSiTcDYVgn3FY4nO/RqHIhij5fwCKnn LF9BMveR+vJb+eq7RHnWpn8ls1sEDRUQpEKSe8zGL6i0fhRUnonFXRgV8PTDsm1Ml6yl 1HpJDRrKuzDIohvUu3UskL95gOHiRKKjzS3ZsHhbOvqTB58AIXpUXUq0C+Wf1B6i7MPJ ldql04gwGeE/WSjaPQ2eqJVOpg02k6vBfBeHr6XFY6gQo/K6om+0VRYs0ZkfFDLTCZdu Wyyg== X-Gm-Message-State: APjAAAUoueOvT5QqFFjPyS8yOlebj30P2WK7KkgXHT8GVbnBtbI6odlh ZKE0F5SZe88Mr3cslUJti/tWS7wP6iNN8jv9PEE= X-Google-Smtp-Source: APXvYqzw990rUycByROw4zkF62pkWP9AxUnKuCmqvpErgJHhdY1qzP2HJrK57T1jcKoZyCbsLlq31GqXxqwmVN3UQ/U= X-Received: by 2002:a92:dd12:: with SMTP id n18mr403074ilm.9.1574206711770; Tue, 19 Nov 2019 15:38:31 -0800 (PST) MIME-Version: 1.0 References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> In-Reply-To: <877e3vqx9r.fsf@mail.linkov.net> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Tue, 19 Nov 2019 23:38:20 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Nov 19, 2019 at 11:20 PM Juri Linkov wrote: > > > I can't confirm 100% if this is the right bug to report this to, but > > the recent changes by Juri, which make yes-or-no-p use the minibuffer > > for reading, break fido-mode's icomplete-magic-kill command > > (apologies if that's not the exact name). > > Please provide step-by-step recipe, it's hard to see what is wrong. > I tried everything, and don't see anything unusual. Sorry Juri, I was reporting from my mobile phone. An easy recipe: Emacs -Q M-x fido-mode (defalias 'yes-or-no-p 'y-or-n-p) ;; a common custmization C-x b C-k ;; to kill the Messages buffer Before your changes to `y-or-n-p` this worked well, afterwards I get the "Attempt to use minibuffer inside minibuffer" error. Bear in mind that fido-mode is very new. Also bear in mind that the problem is already present when yes-or-no-p is used. I think a good fix is for icomplete to do this (and for you to do nothing :-) ) diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 8410ca5c3e..bf1d69a4c5 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -241,6 +241,8 @@ icomplete-fido-kill (category (alist-get 'category (cdr md))) (all (completion-all-sorted-completions)) (thing (car all)) + (enable-recursive-minibuffers t) + (icomplete-mode nil) (action (pcase category (`buffer WDYT? Jo=C3=A3o From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Nov 2019 10:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157424732228254 (code B ref 17272); Wed, 20 Nov 2019 10:56:02 +0000 Received: (at 17272) by debbugs.gnu.org; 20 Nov 2019 10:55:22 +0000 Received: from localhost ([127.0.0.1]:49006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXNdq-0007Ld-0e for submit@debbugs.gnu.org; Wed, 20 Nov 2019 05:55:22 -0500 Received: from quimby.gnus.org ([95.216.78.240]:40262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXNdj-0007L5-Dy; Wed, 20 Nov 2019 05:55:15 -0500 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iXNdY-0006lt-RR; Wed, 20 Nov 2019 11:55:07 +0100 From: Lars Ingebrigtsen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <878sobqxb4.fsf@mail.linkov.net> Date: Wed, 20 Nov 2019 11:55:04 +0100 In-Reply-To: <878sobqxb4.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 20 Nov 2019 00:28:15 +0200") Message-ID: <87sgmikebb.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > The first case is when doing completion, the message > "Making completion list..." is displayed in the minibuffer > for 2 seconds. I don't understand why this message is needed at all, > but at leas [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ingebrigtsen.no] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Juri Linkov writes: > The first case is when doing completion, the message > "Making completion list..." is displayed in the minibuffer > for 2 seconds. I don't understand why this message is needed at all, > but at least this patch restores its previous behavior > that displays that message in the echo area and doesn't wait. Perhaps some completion functions can take a lot of time, so we message preemptively? We do a lot of the "just in case" messaging in Emacs, unfortunately. (There's a wishlist bug report in the bug tracker to add something like (with-delayed-message (0.5 "This sure is taking long...") (here-is-some-code)) that would only do the message if the body of the form takes longer than the timeout.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Nov 2019 22:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Lars Ingebrigtsen , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157429004923116 (code B ref 17272); Wed, 20 Nov 2019 22:48:02 +0000 Received: (at 17272) by debbugs.gnu.org; 20 Nov 2019 22:47:29 +0000 Received: from localhost ([127.0.0.1]:51024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXYky-00060k-Qw for submit@debbugs.gnu.org; Wed, 20 Nov 2019 17:47:29 -0500 Received: from bonobo.birch.relay.mailchannels.net ([23.83.209.22]:56790) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXYkl-000606-D3; Wed, 20 Nov 2019 17:47:16 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 13640500A49; Wed, 20 Nov 2019 22:47:14 +0000 (UTC) Received: from pdx1-sub0-mail-a44.g.dreamhost.com (100-96-196-51.trex.outbound.svc.cluster.local [100.96.196.51]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 65E5C5017E9; Wed, 20 Nov 2019 22:47:13 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a44.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Wed, 20 Nov 2019 22:47:13 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Cold-Arch: 1e1de25726b7608f_1574290033732_3596591818 X-MC-Loop-Signature: 1574290033732:3942751158 X-MC-Ingress-Time: 1574290033731 Received: from pdx1-sub0-mail-a44.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a44.g.dreamhost.com (Postfix) with ESMTP id 7A80A832D8; Wed, 20 Nov 2019 14:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=ZBgPWiF1HKiypXCpAA67/XSBAQM=; b= cDxIQhFW70GwK2k5f7cuJiqaBHDFKj5o22F0qVdFnXIHrLGeGbc2mD1CQBzTLEtz GoNR5YIbTNu/sUzysY4gu7Zrq36qzYaYdXFkX/lIwBFSv3Ixz3W/zNWxYJEjVsA+ bcSSJUUL/Ge3LLJ9AXCSsKLIvAxS/J+UUz1AEhW+aUM= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a44.g.dreamhost.com (Postfix) with ESMTPSA id 4A538832D4; Wed, 20 Nov 2019 14:47:00 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a44 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> Date: Thu, 21 Nov 2019 00:10:59 +0200 In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 19 Nov 2019 23:38:20 +0000") Message-ID: <87v9reqk6o.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Emacs -Q > M-x fido-mode > (defalias 'yes-or-no-p 'y-or-n-p) ;; a common custmization > C-x b > C-k ;; to kill the Messages buffer > > Before your changes to `y-or-n-p` this worked well, afterwards > I get the "Attempt to use minibuffer inside minibuffer" error. > > Bear in mind that fido-mode is very new. Also bear in mind > that the problem is already present when yes-or-no-p is used. > > I think a good fix is for icomplete to do this (and for > you to do nothing :-) ) It's tempting to do nothing :-), but since the problem is already present with yes-or-no-p too, it should be fixed because it's a general problem affecting other commands too. The nil value of enable-recursive-minibuffers by default was intended to avoid confusion for beginners unadvisedly typing such sequences as M-x M-x M-x M-x M-x ... to get out from which is not easy. But for yes/no or y/n questions it should be right to allow recursive minibuffers temporarily: diff --git a/lisp/subr.el b/lisp/subr.el index 20daed623f..2265965c60 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -2847,6 +2848,7 @@ y-or-n-p (t (setq prompt (funcall padded prompt)) (let* ((empty-history '()) + (enable-recursive-minibuffers t) (str (read-from-minibuffer prompt nil (make-composed-keymap y-or-n-p-map query-replace-map) diff --git a/src/fns.c b/src/fns.c index cbb6879223..3ae3192b3d 100644 --- a/src/fns.c +++ b/src/fns.c @@ -2805,15 +2805,18 @@ DEFUN ("yes-or-no-p", Fyes_or_no_p, Syes_or_no_p, 1, 1, 0, AUTO_STRING (yes_or_no, "(yes or no) "); prompt = CALLN (Fconcat, prompt, yes_or_no); + ptrdiff_t count = SPECPDL_INDEX (); + specbind (Qenable_recursive_minibuffers, Qt); + while (1) { ans = Fdowncase (Fread_from_minibuffer (prompt, Qnil, Qnil, Qnil, Qyes_or_no_p_history, Qnil, Qnil)); if (SCHARS (ans) == 3 && !strcmp (SSDATA (ans), "yes")) - return Qt; + return unbind_to (count, Qt); if (SCHARS (ans) == 2 && !strcmp (SSDATA (ans), "no")) - return Qnil; + return unbind_to (count, Qnil); Fding (Qnil); Fdiscard_input (); From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Nov 2019 22:48:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157429005023130 (code B ref 17272); Wed, 20 Nov 2019 22:48:03 +0000 Received: (at 17272) by debbugs.gnu.org; 20 Nov 2019 22:47:30 +0000 Received: from localhost ([127.0.0.1]:51028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXYkz-00060u-Lm for submit@debbugs.gnu.org; Wed, 20 Nov 2019 17:47:29 -0500 Received: from antelope.elm.relay.mailchannels.net ([23.83.212.4]:31255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXYkr-00060L-HH; Wed, 20 Nov 2019 17:47:22 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 08D1220783; Wed, 20 Nov 2019 22:47:20 +0000 (UTC) Received: from pdx1-sub0-mail-a44.g.dreamhost.com (100-96-196-51.trex.outbound.svc.cluster.local [100.96.196.51]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 87F3B2072C; Wed, 20 Nov 2019 22:47:19 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a44.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Wed, 20 Nov 2019 22:47:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Juvenile-Average: 29a981040805df90_1574290039798_1064999566 X-MC-Loop-Signature: 1574290039798:4026598271 X-MC-Ingress-Time: 1574290039798 Received: from pdx1-sub0-mail-a44.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a44.g.dreamhost.com (Postfix) with ESMTP id 46E1E832D4; Wed, 20 Nov 2019 14:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=jT8DFSyF4CLCO7YSep3jvyBXQ+s=; b= Qvni3TKdc3RGWU/Zh+6iYR8diNorAqZfNr6eFSnhx+wP7J5nRddu1UZTo3HmUf16 ObPPwFLFOPXOwYgBX98Zx+MJms5fn8C3THQmAHTfuVZ5KTi2uLudNXK26jRsYFuc ZLPzK9kkP42FVjAYXWdARdGAnh+YAYaSmE+frRmMe+I= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a44.g.dreamhost.com (Postfix) with ESMTPSA id E8153832D5; Wed, 20 Nov 2019 14:47:12 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a44 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <878sobqxb4.fsf@mail.linkov.net> <87sgmikebb.fsf@gnus.org> Date: Thu, 21 Nov 2019 00:18:57 +0200 In-Reply-To: <87sgmikebb.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 20 Nov 2019 11:55:04 +0100") Message-ID: <87lfsaqjhq.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> The first case is when doing completion, the message >> "Making completion list..." is displayed in the minibuffer >> for 2 seconds. I don't understand why this message is needed at all, >> but at least this patch restores its previous behavior >> that displays that message in the echo area and doesn't wait. > > Perhaps some completion functions can take a lot of time, so we message > preemptively? We do a lot of the "just in case" messaging in Emacs, > unfortunately. > > (There's a wishlist bug report in the bug tracker to add something like > > (with-delayed-message (0.5 "This sure is taking long...") > (here-is-some-code)) > > that would only do the message if the body of the form takes longer than > the timeout.) I see, it's in bug#22922 and bug#19776. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Nov 2019 23:45:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Lars Ingebrigtsen , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157429349028828 (code B ref 17272); Wed, 20 Nov 2019 23:45:05 +0000 Received: (at 17272) by debbugs.gnu.org; 20 Nov 2019 23:44:50 +0000 Received: from localhost ([127.0.0.1]:51097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXZeT-0007Up-VS for submit@debbugs.gnu.org; Wed, 20 Nov 2019 18:44:50 -0500 Received: from mail-wr1-f41.google.com ([209.85.221.41]:43564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXZeQ-0007UT-FH; Wed, 20 Nov 2019 18:44:47 -0500 Received: by mail-wr1-f41.google.com with SMTP id n1so2040228wra.10; Wed, 20 Nov 2019 15:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=NPsW82qeYFeSxLioBzS262RGRo4BjSAfphApmKmAILI=; b=DeFzdaHlPm61AvVJEJaG0QeEffv+0t7ltCqzIfdcupROqyP4OOKawUA71AlRUeZMI2 dgUCmKG3QKwf5go7MZkQyUVFBnCXYnE1kgzDxUUg3YfkswO/TszJkXN26rn8uOgkOsUq A2ksCf3CqAwPVxEhgw4jHusMCRi/J+emFsdw/BcFuKsdcZEQNSctrbvpmIDkOKt144cL FDD2VJdO6j5DCuntKIFuzg5lA7a27n0zAZ7ZEBDOQ4zu6CvWmuYXT6KJpEW5ccXU7d7A c4e/l/Yxo09rB8/AmKxtg31Ls8cwcTpYVOiGXYQ8Zzc/mh07gy98ex4R/+DBXpdYmxVj ZoIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=NPsW82qeYFeSxLioBzS262RGRo4BjSAfphApmKmAILI=; b=FplTH9/WaMQNWQp6w5RMTLnhjCuw5PpFLXS6mZ0bDsoyLTxpYWH1jHXKM9okwOKk/t VjOSgchVPcGJRfUrSFUsUrieZvqNaT2QgAe8JQVbZCbCV1m4xjkAIKWAyVpjlXXGit7J 2yEGzNEwmOEZSLnzK/XDppBV+StEfKIDwlbI56jO5YBl1kd368COrSJdVXnvuzFeD/Kz dCexh77el2Dc818HYOkwfwMjBGERUkX5G0yOJGz9go1pcUYLSV2tNoebdyxwVfCxrniX euLI0MguuMzKIODopaKsi4N5a3WXwgbJuC2IET7eWI3+FHX5inv2HmEbBku14q13BUAY a/Rg== X-Gm-Message-State: APjAAAVmmuyFB05BUbdBZrt8LGPcJy2v4X8RqyhkavKWRo4oNJiOUQQ3 qszzM7N6oTFZWSXnf+s+S/g= X-Google-Smtp-Source: APXvYqzBi0qQkcoSubpgVXE8JhCWhLy9XMgDBBJq7znvQlf4YVhjw3LSosilq3jg3zb/Hi2BZkNnxg== X-Received: by 2002:a05:6000:1286:: with SMTP id f6mr3999279wrx.44.1574293480369; Wed, 20 Nov 2019 15:44:40 -0800 (PST) Received: from lolita.yourcompany.com ([2001:818:d820:9500:1ebb:afd8:ab26:f0f6]) by smtp.gmail.com with ESMTPSA id j2sm1001328wrt.61.2019.11.20.15.44.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Nov 2019 15:44:38 -0800 (PST) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> Date: Wed, 20 Nov 2019 23:44:28 +0000 In-Reply-To: <87v9reqk6o.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 21 Nov 2019 00:10:59 +0200") Message-ID: <878soacdur.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Juri Linkov writes: >> Emacs -Q >> M-x fido-mode >> (defalias 'yes-or-no-p 'y-or-n-p) ;; a common custmization >> C-x b >> C-k ;; to kill the Messages buffer >> >> Before your changes to `y-or-n-p` this worked well, afterwards >> I get the "Attempt to use minibuffer inside minibuffer" error. >> >> Bear in mind that fido-mode is very new. Also bear in mind >> that the problem is already present when yes-or-no-p is used. >> >> I think a good fix is for icomplete to do this (and for >> you to do nothing :-) ) > > It's tempting to do nothing :-), but since the problem is > already present with yes-or-no-p too, it should be fixed > because it's a general problem affecting other commands too. I tend to agree, but it's a longstanding thing in Emacs, so I would be very wary of touching it (at least until we get some more opinions). > > The nil value of enable-recursive-minibuffers by default was intended > to avoid confusion for beginners unadvisedly typing such sequences as > M-x M-x M-x M-x M-x ... to get out from which is not easy. That may be true, but are you sure there aren't other problems being avoided by it? Let me give you and example: in icomplete-mode, there is a post-command-hook that displays some overlays in the minibuffer. Now, if we take your patch, indeed icomplete-mode doesn't have to worry about enable-recursive-minibuffers in the example I gave you. This is good, no more error message. However, that also means that instead of an annoying error message, you get another confusing bug where the post-command-hook will prevail in the recursive minibuffer, which just doesn't make sense when answering just yes-or-no. In this particular case, I additionally protected the code against this, but what I'm saying is that other bugs may be uncovered by your patch that are today hidden behind the annoying-but-reasonable error message. Jo=C3=A3o From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Nov 2019 08:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Lars Ingebrigtsen , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157432458822393 (code B ref 17272); Thu, 21 Nov 2019 08:24:01 +0000 Received: (at 17272) by debbugs.gnu.org; 21 Nov 2019 08:23:08 +0000 Received: from localhost ([127.0.0.1]:51208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXhk3-0005p4-LW for submit@debbugs.gnu.org; Thu, 21 Nov 2019 03:23:08 -0500 Received: from mout.gmx.net ([212.227.15.18]:53423) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXhk1-0005oL-6T; Thu, 21 Nov 2019 03:23:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574324574; bh=xDRGtmTcSmkTzfnJpUcv+eYfySvchPOkA4HVdNw1jbI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=hns4B38LdPeayyl2zt9uDIAOJtcsTAIEO3RQQKIWWoipF9zUx+L6J9tWLvL1RVQNn Ho8qwVa594tOGbZ7ERvlGAKdYikAL+s/3DqSIGrbGyABJe4jTOfB6o6NIJQMHL3a4e XSVLfpWteswpZZMI7aQq/sulTgXgv/lF8Po/j+ig= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.206]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MUXtS-1iOs2A2fz6-00QRZS; Thu, 21 Nov 2019 09:22:54 +0100 References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> From: martin rudalics Message-ID: <6d3c4659-0ffc-a847-e5ff-0d7cff73cbcd@gmx.at> Date: Thu, 21 Nov 2019 09:22:51 +0100 MIME-Version: 1.0 In-Reply-To: <87v9reqk6o.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:auWcp99nttUxnyksHle6N/g7rPn9p+MWrPZxnyFhX5c4YlLBCAF rIyaRyD41+E6IHyuv87rAnUkrclov4gdTJLaan3chE+N8wi40rEnMtR+p0aGNn2lvVtszoi heU0D/l0S5aGL4BMwfEcAU7W7qDzACR+67VmW2ffJdBG7KPeXNAZQm6NF4zcJDY00erGHBk rfj/wq7RIeW5cyN2KrMwQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:peouGawlE3A=:B970ZZB9y2ZcdAlObNIrGI 2qcUeROxRdY/V1lXR1hBhFB/qvxnuC3Zn3/E9HXgKYMR2j+tT85AWF73YWjtYCaOqmzkchZsj zGGhnxY+zca6zgpWuo/gvUehqIhJBmR1WplS91N2duvoHajF8swy2JJQP6cqRvrpsB3q04Esi FiiVEHFdh6eSurbVwoIvo/CkvvOKPK+grQ/nmi+xH0JGw4SfBWCJrtnpn9uldzZ+7pKPkOpMJ 1gfn+6vTyHyYlmKTp7tjAnh/vqHeJ9j4H8rX+z42ByULshBbkMxSIqIQDOderPxt/2wKzhGS5 88GF8ufh48jFpHlndru1FeiKTWZpcpfPWtBxWRTe3avfgVVX84E7TpR5Pg7zYD5dhJiKmVmlR qS22gRXeTt1uYSkTsVKja3YupIy//WLB9wUKJuQeYlqY140a8d2Z4GntL4B/IvNCaa5kSMyUO qLc/E4Sub8UtXpQPGMt2kvs3UtxX90r8DoLeGVqd9D+QT+Rfh8n38VNvrGitenQOQ++cpn7Li l2VxjfFLEJnlt2cfMM1Ga9dBjXI0nFdAMsA2cb06S+3DrjhzwHk/ojBCOfNBvbMb4FnAHNXD1 gCkpn3Tbm39MpPspY1oTYnIdaWUsuGIuVfsi5gwXM8h32FWumaw5suluR9WNKzg9gCuOUMUhn nY1z9FuID7F73aeeZUovCS8ic68lv8/URtHiS8gzQfXfZ5cRtJTRTGM3wr5IG8TFgmQ7wspWD JWzgitAzeZMPMmg1c1/x6xHTdg3jlsIat/mB9Htc8lcTZdwudGGvB97oS9KiDNnSui6R7bqXC tX1uQ1iHP3pONsYZPkuITK/meM7zIfoVB+wx6qygcyhD7qWirV8pM7XOVJK5z0sptgTF2yT8c wKl4yIj993vuAmurEwrHeJQXIR2Wq+Olk102KkNweDxh7BH1ZZXvy6mzcEutroJ0KSVbi5TB7 bf/pF6o4sLGUv4WBWahnGrWp0jzPmNoj7hJ4cXCQ7kV9nQ3mWorvTwkfZhEXXGP02jz61TZvt z4ReJUr7lxVebJ3ClR061QhFctmUDxHAPu6VGWGHTlBzIUjxiBZYujK8u2H1f+LxgtEuQZ5SO oPiKiKaljM6Td2xSLcpABZwA5hoQ5/SPKhtCZ52xP4zj2oTuZj09vozjDduotHd4xN+IPR+C8 PiPUuhzVnudHDw/A4gzIGVp8+501jlqZ44D8SiZEXvSudzgwC+djtrGIvqAOXSeaAG8Q6oKwK uUJHyeUy5lbPFy2JxkWC3QND/liQTE1r47C9sSEn59oaYeG1RzeivZSXGKRo= X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Shouldn't this one > + (enable-recursive-minibuffers t) be protected too? martin From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Nov 2019 23:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Michael Heerdegen , 17272@debbugs.gnu.org, Lars Ingebrigtsen , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157437742422049 (code B ref 17272); Thu, 21 Nov 2019 23:04:02 +0000 Received: (at 17272) by debbugs.gnu.org; 21 Nov 2019 23:03:44 +0000 Received: from localhost ([127.0.0.1]:53467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXvUD-0005jW-Ql for submit@debbugs.gnu.org; Thu, 21 Nov 2019 18:03:42 -0500 Received: from black.elm.relay.mailchannels.net ([23.83.212.19]:29658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXvUA-0005jH-6E; Thu, 21 Nov 2019 18:03:39 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id EE0BA6A0D78; Thu, 21 Nov 2019 23:03:36 +0000 (UTC) Received: from pdx1-sub0-mail-a7.g.dreamhost.com (100-96-87-246.trex.outbound.svc.cluster.local [100.96.87.246]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5B8AD6A20E3; Thu, 21 Nov 2019 23:03:36 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a7.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 21 Nov 2019 23:03:36 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Daffy-Exultant: 4deb5770673f4e19_1574377416631_2981569835 X-MC-Loop-Signature: 1574377416631:3777984559 X-MC-Ingress-Time: 1574377416631 Received: from pdx1-sub0-mail-a7.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a7.g.dreamhost.com (Postfix) with ESMTP id DE25182B18; Thu, 21 Nov 2019 15:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=3sGb7GtlIxXzN0zmifqvjTQnhK0=; b= AIPDCtA8bjakP4hmTscq0HLVm6qaJvQMpBbiSDZU6mbgSQud2LngGbfpv3c0zd81 /S4tfQwxwiy8DJ03uVdD0ccSjHjCGEt5TQhDxCFG72WBD4TR+Da04RvnEfI6dYbR r6l1IgOCuQHR0+t5fO1RWGT1qbGmijt3o3ZYu0jCd1Q= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a7.g.dreamhost.com (Postfix) with ESMTPSA id D853282ACF; Thu, 21 Nov 2019 15:03:27 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a7 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> <878soacdur.fsf@gmail.com> Date: Thu, 21 Nov 2019 23:39:42 +0200 In-Reply-To: <878soacdur.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 20 Nov 2019 23:44:28 +0000") Message-ID: <878so8lxyx.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> It's tempting to do nothing :-), but since the problem is >> already present with yes-or-no-p too, it should be fixed >> because it's a general problem affecting other commands too. > > I tend to agree, but it's a longstanding thing in Emacs, so I would be > very wary of touching it (at least until we get some more opinions). Many other important minibuffer-reading functions already let-bind enable-recursive-minibuffers to t: custom-variable-prompt find-function-read describe-function describe-variable describe-symbol read-input-method-name read-char-by-name read-passwd and many other. So yes-or-no-p could do the same because it's important for users to be able to answer yes/no questions regardless of whether they activated the minibuffer intentionally or by mistake. >> The nil value of enable-recursive-minibuffers by default was intended >> to avoid confusion for beginners unadvisedly typing such sequences as >> M-x M-x M-x M-x M-x ... to get out from which is not easy. > > That may be true, but are you sure there aren't other problems being > avoided by it? > > Let me give you and example: in icomplete-mode, there is a > post-command-hook that displays some overlays in the minibuffer. Now, > if we take your patch, indeed icomplete-mode doesn't have to worry about > enable-recursive-minibuffers in the example I gave you. This is good, > no more error message. However, that also means that instead of an > annoying error message, you get another confusing bug where the > post-command-hook will prevail in the recursive minibuffer, which just > doesn't make sense when answering just yes-or-no. > > In this particular case, I additionally protected the code against this, > but what I'm saying is that other bugs may be uncovered by your patch > that are today hidden behind the annoying-but-reasonable error message. All experienced Emacs users have enable-recursive-minibuffers enabled, so everything should work regardless of the value of enable-recursive-minibuffers. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Nov 2019 23:04:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: martin rudalics Cc: Michael Heerdegen , Lars Ingebrigtsen , 17272@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157437743222081 (code B ref 17272); Thu, 21 Nov 2019 23:04:03 +0000 Received: (at 17272) by debbugs.gnu.org; 21 Nov 2019 23:03:52 +0000 Received: from localhost ([127.0.0.1]:53472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXvUN-0005k4-WC for submit@debbugs.gnu.org; Thu, 21 Nov 2019 18:03:52 -0500 Received: from camel.birch.relay.mailchannels.net ([23.83.209.29]:17533) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXvUI-0005jn-Hv; Thu, 21 Nov 2019 18:03:47 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5416C141A1C; Thu, 21 Nov 2019 23:03:45 +0000 (UTC) Received: from pdx1-sub0-mail-a7.g.dreamhost.com (100-96-87-246.trex.outbound.svc.cluster.local [100.96.87.246]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 145B51415C8; Thu, 21 Nov 2019 23:03:45 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a7.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 21 Nov 2019 23:03:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Continue-Plucky: 591b8f4f7db16788_1574377425167_1073163606 X-MC-Loop-Signature: 1574377425167:2944486776 X-MC-Ingress-Time: 1574377425167 Received: from pdx1-sub0-mail-a7.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a7.g.dreamhost.com (Postfix) with ESMTP id 9E46282B18; Thu, 21 Nov 2019 15:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=Y003XSL9qXIsmlr4bo48RfDfhDY=; b= kfD+9Lz5DZKtuFYXvfcRueQAEIPxpTnW9tSm7wyfIo9XAEK6p9+bXrHiDd7blfdX brOr9iNkYaS4hTWtVRgFWqRQOu6JxU47CVRahBQU/A7aXeh3z5F5hwMc3qtR8CTl /BbnJXUyPTw/2kujkG0T9bu+kk6RdbkSR61PvrVrxpQ= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 7F62B82B08; Thu, 21 Nov 2019 15:03:35 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a7 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> <6d3c4659-0ffc-a847-e5ff-0d7cff73cbcd@gmx.at> Date: Thu, 21 Nov 2019 23:44:44 +0200 In-Reply-To: <6d3c4659-0ffc-a847-e5ff-0d7cff73cbcd@gmx.at> (martin rudalics's message of "Thu, 21 Nov 2019 09:22:51 +0100") Message-ID: <871ru0lxvj.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Shouldn't this one > >> + (enable-recursive-minibuffers t) > > be protected too? Protected from what? From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Nov 2019 23:04:20 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157437745622169 (code B ref 17272); Thu, 21 Nov 2019 23:04:20 +0000 Received: (at 17272) by debbugs.gnu.org; 21 Nov 2019 23:04:16 +0000 Received: from localhost ([127.0.0.1]:53480 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXvUZ-0005l5-If for submit@debbugs.gnu.org; Thu, 21 Nov 2019 18:04:15 -0500 Received: from beige.elm.relay.mailchannels.net ([23.83.212.16]:9009) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXvUO-0005k3-Me; Thu, 21 Nov 2019 18:03:53 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 68B275E101A; Thu, 21 Nov 2019 23:03:51 +0000 (UTC) Received: from pdx1-sub0-mail-a7.g.dreamhost.com (100-96-87-246.trex.outbound.svc.cluster.local [100.96.87.246]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 022145E17C2; Thu, 21 Nov 2019 23:03:50 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a7.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 21 Nov 2019 23:03:51 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Bitter-Zesty: 6882ea4b1cd3463f_1574377431238_3294895798 X-MC-Loop-Signature: 1574377431238:3608736308 X-MC-Ingress-Time: 1574377431237 Received: from pdx1-sub0-mail-a7.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a7.g.dreamhost.com (Postfix) with ESMTP id 3745482ACF; Thu, 21 Nov 2019 15:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=K04rrb8PdM8hSa9/RkZWRF/XxUw=; b= B8a/9O80n5IZSBC5OzhMI/VYa7yE8Wb6oBqBDZyvgye0ZuQFDpiWeAgUexUwqovc cRCSkV15g8cyfHK1ebV79KDnCyQmjTGY4QNml7TIHvtypgdvBapa6PwtGkqkIxTm g46vyo3cmrvRrEN8IVtHk2n9LpFVWGsC8BGOuUCTN7g= Received: from mail.jurta.org (m91-129-102-1.cust.tele2.ee [91.129.102.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 6474C82B0E; Thu, 21 Nov 2019 15:03:44 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a7 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <878sobqxb4.fsf@mail.linkov.net> <87sgmikebb.fsf@gnus.org> <87lfsaqjhq.fsf@mail.linkov.net> Date: Thu, 21 Nov 2019 23:54:13 +0200 In-Reply-To: <87lfsaqjhq.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 21 Nov 2019 00:18:57 +0200") Message-ID: <87tv6wkiqa.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> The first case is when doing completion, the message >>> "Making completion list..." is displayed in the minibuffer >>> for 2 seconds. I don't understand why this message is needed at all, >>> but at least this patch restores its previous behavior >>> that displays that message in the echo area and doesn't wait. >> >> Perhaps some completion functions can take a lot of time, so we message >> preemptively? We do a lot of the "just in case" messaging in Emacs, >> unfortunately. >> >> (There's a wishlist bug report in the bug tracker to add something like >> >> (with-delayed-message (0.5 "This sure is taking long...") >> (here-is-some-code)) >> >> that would only do the message if the body of the form takes longer than >> the timeout.) > > I see, it's in bug#22922 and bug#19776. But should the function itself report its own progress using progress-reporter-update? From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Nov 2019 23:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157437764222659 (code B ref 17272); Thu, 21 Nov 2019 23:08:01 +0000 Received: (at 17272) by debbugs.gnu.org; 21 Nov 2019 23:07:22 +0000 Received: from localhost ([127.0.0.1]:53524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXvXm-0005tN-0K for submit@debbugs.gnu.org; Thu, 21 Nov 2019 18:07:22 -0500 Received: from quimby.gnus.org ([95.216.78.240]:38558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iXvXg-0005sw-B1; Thu, 21 Nov 2019 18:07:20 -0500 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iXvXY-0005DZ-5z; Fri, 22 Nov 2019 00:07:10 +0100 From: Lars Ingebrigtsen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <878sobqxb4.fsf@mail.linkov.net> <87sgmikebb.fsf@gnus.org> <87lfsaqjhq.fsf@mail.linkov.net> <87tv6wkiqa.fsf@mail.linkov.net> Date: Fri, 22 Nov 2019 00:07:06 +0100 In-Reply-To: <87tv6wkiqa.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 21 Nov 2019 23:54:13 +0200") Message-ID: <87ftigvnfp.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > But should the function itself report its own progress > using progress-reporter-update? No, I think that's too complicated. It doesn't know how long it's going to take, so it can't report a percentage done or anything. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linkov.net] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Juri Linkov writes: > But should the function itself report its own progress > using progress-reporter-update? No, I think that's too complicated. It doesn't know how long it's going to take, so it can't report a percentage done or anything. But it could do "...done" at the end if it has decided to show the initial string. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Nov 2019 07:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: michael_heerdegen@web.de, larsi@gnus.org, 17272@debbugs.gnu.org, joaotavora@gmail.com, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157440891725128 (code B ref 17272); Fri, 22 Nov 2019 07:49:02 +0000 Received: (at 17272) by debbugs.gnu.org; 22 Nov 2019 07:48:37 +0000 Received: from localhost ([127.0.0.1]:53682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iY3gC-0006X9-Pe for submit@debbugs.gnu.org; Fri, 22 Nov 2019 02:48:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58587) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iY3g9-0006Wp-Q4; Fri, 22 Nov 2019 02:48:35 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49618) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iY3g4-0002eo-3p; Fri, 22 Nov 2019 02:48:28 -0500 Received: from [176.228.60.248] (port=3656 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iY3g2-0003I8-Q0; Fri, 22 Nov 2019 02:48:27 -0500 Date: Fri, 22 Nov 2019 09:48:41 +0200 Message-Id: <83r220wduu.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <878so8lxyx.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 21 Nov 2019 23:39:42 +0200) References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> <878soacdur.fsf@gmail.com> <878so8lxyx.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Date: Thu, 21 Nov 2019 23:39:42 +0200 > Cc: Michael Heerdegen , 17272@debbugs.gnu.org, > Lars Ingebrigtsen , 19064@debbugs.gnu.org > > All experienced Emacs users have enable-recursive-minibuffers enabled I don't, FWIW. So please don't build any revolutionary UI changes on that wrong assumption. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Nov 2019 08:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: Michael Heerdegen , Lars Ingebrigtsen , 17272@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157441015427014 (code B ref 17272); Fri, 22 Nov 2019 08:10:02 +0000 Received: (at 17272) by debbugs.gnu.org; 22 Nov 2019 08:09:14 +0000 Received: from localhost ([127.0.0.1]:53705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iY40A-00071Z-Cs for submit@debbugs.gnu.org; Fri, 22 Nov 2019 03:09:14 -0500 Received: from mout.gmx.net ([212.227.15.15]:56727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iY408-00071E-DL; Fri, 22 Nov 2019 03:09:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574410141; bh=c95MZgl7ojQKNkTpAyEt15kXlNjaDGpHvuowl9E5ZHw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=JB5vYma6ckIeJtnAo9w+Q5wJDOWMnlAljmIIEjRzfP0qujosgkpNWk4EdlSpMYRLR ArklfMPSzGkrOs178uGPiRGFlXTIswTObMW81zLQlzvclxHfLkyjpd7CRjiQwA5fUZ YZG+TflCNs3WzIe5eeUFpyEwcJWCe9AQuq+MdHdE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.35]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MLzBj-1iGG202FCj-00Ht3E; Fri, 22 Nov 2019 09:09:01 +0100 References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> <6d3c4659-0ffc-a847-e5ff-0d7cff73cbcd@gmx.at> <871ru0lxvj.fsf@mail.linkov.net> From: martin rudalics Message-ID: <30ac04db-fa08-ffe6-f517-36b2b3815b1d@gmx.at> Date: Fri, 22 Nov 2019 09:08:59 +0100 MIME-Version: 1.0 In-Reply-To: <871ru0lxvj.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:fo1srTjSbco2cTf1WZhGKoU4+EBsTu7RM0PKLByhblqsCCVmu4Y PSaQKk33b4qpOFc1VEZ4zTJwwnHlJ0EpJBFaXJoq6Ou9pxP4mfeA3vps8X6RdEjeGwRRJc4 y6MD/Ii7EK8QkPTk6HXU1bvHNsegnGTr9qMy4yto6lrZkPYAtJ7WbXDIxIOvhIhIlpjL1IR 6yqzNuJB1Xvu5IPNG+9aQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:qgLifXWG7rg=:6gmAjn+OkTwJfjFG5TO7g6 f/0e5zrKiUyHZKa/hSl/aZ7NcZQaEgpIaWDKB5XP0RRJ1OileBnPQWR556AAAWH5pMOgvx+Fl dSNeLb3erZU4ytls26qp4ilLIJVNrV801Fj6RTufkV/MEs05MWJ/6eyxw0MmyLWIBMb4mpHaG RHkJ3TJuOWV92easefaDuIAa845hpOIvkFtYbWkDsZ5tth8xkbyIykFgCLXf+/f+dtX61pAI7 Z5DNBTY8K3HthU6Idz9UbLcCilY31e0r5h4+syHrHwE0FutW0ChUiurRE9xDbPQgenwOx3yMk BFTg3LDsdMNZcRPymrB9YoyzsFtpgViujd1Zqe5rNdVqxCnvQVcma8MY1PN4nIYQmP+zCca0p te9+9qxcL4jxyFnvV3r/cZ+kYVYJ5g7gcdQAQNGYluR+FGgKjrAoxojnv+lmandOBJ9RLCnsy nDLRVwaftIhSnvemXZGNoqGljtVND86pWnN6gAN9dnCYnEI3Q287c88hvyPSrqXkdGo5paFI5 CGlA4Mjmtvdt0BY0TYqRHWhLwL1kGNAmsmORamN8WFRRr6YQKJeLfE0F4CBUaoJBGWzvf7juj lz1Xad8WKI+pAx0moeBnEE05lele9y11QmPXYnkNUIrplnX8Vu1d1MZX/0b9La2n+yG1fc8XW SVtY/+7Op23u82kbgRYdV8gpkFTXRXA9HZ1129xea8wWM4V8U8p0pb4L3lSEEfwK7dBDnOAT5 R9EfdLQYRIz+26BXHvrz52Wf2WrtzWIm7Dw3JrgJ00ajuOvJiHLdffJQmBI0OZY0NyGTgBxUv nzYYG92UgUbLzYRofH7y5GbF3EmjPTh7pOpNgw8eD66DCq7x2Hk5EArCN8ezwQKIorVG1zdrC QwIsMjmOVkxhShWH4sGZcL50+HVoXpzl96omW1MEgzPRXC+fgqC2jCLHpPGyaXvyTvbBl6Evj 3Fj21prbWLHrwaaLfSBFp2EnGYhvryeZqXxedEoOvP1rQRijdIizrXRaQsBiz1aQDxLi+ge2I jxTXvp5T4ek0CBxBIbJp9iKg2XeRCo7K2SSqVo1xurs2ENbw3aQOPEJriF6e0dL6NM/fF8jjf ML8VKXvm7ztoPA3AxuVaZ2q0Z88Qy98frQNRma+WxxwkXAubyQOhWJY8jod6y/dn8r0Clq2wm pPTP07LNOO4T3eEOEVcPoVi2JrVuomWJYeoFVHF4QNfUUys5khMUgSn1wKiSJWrLslo6kYnpV je3/vabOZEjb6Bu8wHcQxuXVnF6rZYSmob52f0g== X-Spam-Score: 3.6 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> Shouldn't this one >> >>> + (enable-recursive-minibuffers t) >> >> be protected too? > > Protected from what? From an error that would leave it enabled. What else would be the purpose of + specbind (Qenable_recursive_minibuffers, Qt); Content analysis details: (3.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [212.95.5.35 listed in zen.spamhaus.org] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [212.227.15.15 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.6 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> Shouldn't this one >> >>> + (enable-recursive-minibuffers t) >> >> be protected too? > > Protected from what? From an error that would leave it enabled. What else would be the purpose of + specbind (Qenable_recursive_minibuffers, Qt); Content analysis details: (2.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [212.95.5.35 listed in zen.spamhaus.org] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [212.227.15.15 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager >> Shouldn't this one >> >>> + (enable-recursive-minibuffers t) >> >> be protected too? > > Protected from what? From an error that would leave it enabled. What else would be the purpose of + specbind (Qenable_recursive_minibuffers, Qt); then? martin From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Nov 2019 17:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii , Juri Linkov Cc: michael_heerdegen@web.de, joaotavora@gmail.com, larsi@gnus.org, 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157444430728132 (code B ref 17272); Fri, 22 Nov 2019 17:39:01 +0000 Received: (at 17272) by debbugs.gnu.org; 22 Nov 2019 17:38:27 +0000 Received: from localhost ([127.0.0.1]:55449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYCt0-0007Jb-QM for submit@debbugs.gnu.org; Fri, 22 Nov 2019 12:38:27 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:48212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYCsy-0007JI-CB; Fri, 22 Nov 2019 12:38:25 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAMHYiGr079020; Fri, 22 Nov 2019 17:38:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=seEn2gkwljbP1imT0FeBresI0Pak3OGEttATBlOHGx4=; b=Xhm2UYRIN4PnFsBvHXmlSFmpBSkXUfJUEbB8FLnlgl5MhYLdkaSrHtVx0zexSCF9hrtB CMjkPJBPudBppQfbyg53KYYsSFekNp4OdoU75aLs3vVXveZ0HufS3J8L/x0CAlSDf3VZ ucyjmZ0KXmnVYPs93dA4kTHYfo4Vv7GjAQdbQRONW8s8v0jtR/T7jXqEb40zFBK3Ne7C uJIQL8S6FMqHzBgdJ5QS4JNmHGYYFq8tzcNyyGKYA51otprmw9fNKKION+ymwkMlLeLV XqTZQtSiIYtVNtlUIanVQXp28Rq98Yqc7InDN8deYYLMiPQ/HL3AphqXEMvSXXpl67Yl Bw== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 2wa92qc0hm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Nov 2019 17:38:18 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAMHYsth059250; Fri, 22 Nov 2019 17:38:18 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 2wegqrvq4b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Nov 2019 17:38:18 +0000 Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAMHcASQ017751; Fri, 22 Nov 2019 17:38:10 GMT MIME-Version: 1.0 Message-ID: <134f4787-2885-4288-927a-c2aa7d8d5096@default> Date: Fri, 22 Nov 2019 09:38:09 -0800 (PST) From: Drew Adams References: <<8ea0a3fa-5169-4493-bd54-3ebe47836a35@default>> <<871rugbqmy.fsf@mail.linkov.net>> <<87d0dxyh7z.fsf@gnus.org>> <<53c55db5-d623-4946-af2e-d141e7bc7acd@default>> <<87sgmrpir5.fsf@web.de>> <> <<87mucya2a7.fsf@web.de>> <> <<87mucy4cb2.fsf@web.de>> <<621b98dc-0fe9-4eef-9e11-7580fb446e97@default>> <<87k1822ocn.fsf@web.de>> <<87lfsfmtk0.fsf@mail.linkov.net>> <<874kz3gibu.fsf@gnus.org>> <<87bltaw3xz.fsf@mail.linkov.net>> <<87r224x54p.fsf@mail.linkov.net>> <<87v9rgnv0o.fsf@gnus.org>> <> <<877e3vqx9r.fsf@mail.linkov.net>> <> <<87v9reqk6o.fsf@mail.linkov.net>> <<878soacdur.fsf@gmail.com>> <<878so8lxyx.fsf@mail.linkov.net>> <<83r220wduu.fsf@gnu.org>> In-Reply-To: <<83r220wduu.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4927.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9448 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=819 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911220150 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9448 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=883 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911220150 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > All experienced Emacs users have enable-recursive-minibuffers enabled >=20 > I don't, FWIW. So please don't build any revolutionary UI changes on > that wrong assumption. +1. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Nov 2019 19:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: martin rudalics Cc: Michael Heerdegen , Lars Ingebrigtsen , 17272@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15745359125754 (code B ref 17272); Sat, 23 Nov 2019 19:06:02 +0000 Received: (at 17272) by debbugs.gnu.org; 23 Nov 2019 19:05:12 +0000 Received: from localhost ([127.0.0.1]:57841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYaiU-0001Uc-4o for submit@debbugs.gnu.org; Sat, 23 Nov 2019 14:05:12 -0500 Received: from bisque.elm.relay.mailchannels.net ([23.83.212.18]:42336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYaiP-0001UF-SZ; Sat, 23 Nov 2019 14:05:06 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D2FAA340CFE; Sat, 23 Nov 2019 19:05:04 +0000 (UTC) Received: from pdx1-sub0-mail-a24.g.dreamhost.com (100-96-14-7.trex.outbound.svc.cluster.local [100.96.14.7]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 55E94340CC5; Sat, 23 Nov 2019 19:05:04 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a24.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sat, 23 Nov 2019 19:05:04 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Cooing-Wipe: 3f3ca6dd04ba0050_1574535904609_2729167818 X-MC-Loop-Signature: 1574535904609:1997363891 X-MC-Ingress-Time: 1574535904609 Received: from pdx1-sub0-mail-a24.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTP id 0B5B583DB6; Sat, 23 Nov 2019 11:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=4xH2eCowFnx/ed6lojdPrIDb0qk=; b= PvPeopoIaUikZ4GTEjPTJlAlVcbxQJkrET6mCmjrSlbkyNbokuRQud9LpdkqN8qM QYeuLCzjduv9v6E5OwsQv1wFVZbowt+8uNI7ANy6LxJUcAdtZMD4xqZkNPJ6JV3M yizve+/OSB9Ub/p2xQTCrbFoREj4GbXlI2lHvFH1M/4= Received: from mail.jurta.org (m91-129-105-73.cust.tele2.ee [91.129.105.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 679BC83DB9; Sat, 23 Nov 2019 11:04:54 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a24 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> <6d3c4659-0ffc-a847-e5ff-0d7cff73cbcd@gmx.at> <871ru0lxvj.fsf@mail.linkov.net> <30ac04db-fa08-ffe6-f517-36b2b3815b1d@gmx.at> Date: Sat, 23 Nov 2019 20:56:13 +0200 In-Reply-To: <30ac04db-fa08-ffe6-f517-36b2b3815b1d@gmx.at> (martin rudalics's message of "Fri, 22 Nov 2019 09:08:59 +0100") Message-ID: <8736ee78v6.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> Shouldn't this one >>> >>>> + (enable-recursive-minibuffers t) >>> >>> be protected too? >> >> Protected from what? > > From an error that would leave it enabled. What else would be the > purpose of > > + specbind (Qenable_recursive_minibuffers, Qt); > > then? It seems this is like unwind-protect? Does let-binding need unwind-protect too? From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Nov 2019 19:06:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: michael_heerdegen@web.de, larsi@gnus.org, 17272@debbugs.gnu.org, joaotavora@gmail.com, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15745359145776 (code B ref 17272); Sat, 23 Nov 2019 19:06:05 +0000 Received: (at 17272) by debbugs.gnu.org; 23 Nov 2019 19:05:14 +0000 Received: from localhost ([127.0.0.1]:57846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYaiY-0001V4-4w for submit@debbugs.gnu.org; Sat, 23 Nov 2019 14:05:14 -0500 Received: from bumble.birch.relay.mailchannels.net ([23.83.209.25]:51561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYaiU-0001Ua-1p; Sat, 23 Nov 2019 14:05:12 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9AFD2340D1E; Sat, 23 Nov 2019 19:05:08 +0000 (UTC) Received: from pdx1-sub0-mail-a24.g.dreamhost.com (100-96-4-107.trex.outbound.svc.cluster.local [100.96.4.107]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 24450340DA0; Sat, 23 Nov 2019 19:05:08 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a24.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sat, 23 Nov 2019 19:05:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Robust-Trouble: 6a2ddbe21d0b297b_1574535908408_2045883629 X-MC-Loop-Signature: 1574535908408:1742790545 X-MC-Ingress-Time: 1574535908407 Received: from pdx1-sub0-mail-a24.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTP id 83AD683DB6; Sat, 23 Nov 2019 11:05:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=+6uCkuoXuOH9pIRIhorGxL+v/O4=; b= wRADIKKGUE99Y5HJlUK9uOpQe0Pqcywk+ncJVGBeNqKkOVq3fm/c+61JQTpXiWaQ UZjCHJuqQqWU5j9E8fjFATcYx0WCZqMV4rB4hUXK1fRuQLb6FBg683zOQCp+qbGt C8OBO8/djcRZ+HbMl7YVA77lzHRwegb1m9FmTPDw5Gw= Received: from mail.jurta.org (m91-129-105-73.cust.tele2.ee [91.129.105.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 367C183DB9; Sat, 23 Nov 2019 11:05:03 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a24 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> <878soacdur.fsf@gmail.com> <878so8lxyx.fsf@mail.linkov.net> <83r220wduu.fsf@gnu.org> Date: Sat, 23 Nov 2019 21:02:45 +0200 In-Reply-To: <83r220wduu.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 22 Nov 2019 09:48:41 +0200") Message-ID: <87tv6u5tuu.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > I don't, FWIW. So please don't build any revolutionary UI changes on > that wrong assumption. But do you agree that answering yes/no questions should be allowed anytime regardless of the value of enable-recursive-minibuffers? From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Nov 2019 19:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: michael_heerdegen@web.de, larsi@gnus.org, 17272@debbugs.gnu.org, joaotavora@gmail.com, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15745365256703 (code B ref 17272); Sat, 23 Nov 2019 19:16:02 +0000 Received: (at 17272) by debbugs.gnu.org; 23 Nov 2019 19:15:25 +0000 Received: from localhost ([127.0.0.1]:57863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYasP-0001k3-41 for submit@debbugs.gnu.org; Sat, 23 Nov 2019 14:15:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYasA-0001jO-Tq; Sat, 23 Nov 2019 14:15:11 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iYas5-000758-DA; Sat, 23 Nov 2019 14:15:05 -0500 Received: from [176.228.60.248] (port=4853 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iYas3-0002QN-2Y; Sat, 23 Nov 2019 14:15:05 -0500 Date: Sat, 23 Nov 2019 21:14:50 +0200 Message-Id: <83eexytnf9.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87tv6u5tuu.fsf@mail.linkov.net> (message from Juri Linkov on Sat, 23 Nov 2019 21:02:45 +0200) References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> <878soacdur.fsf@gmail.com> <878so8lxyx.fsf@mail.linkov.net> <83r220wduu.fsf@gnu.org> <87tv6u5tuu.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: joaotavora@gmail.com, michael_heerdegen@web.de, 17272@debbugs.gnu.org, > larsi@gnus.org, 19064@debbugs.gnu.org > Date: Sat, 23 Nov 2019 21:02:45 +0200 > > > I don't, FWIW. So please don't build any revolutionary UI changes on > > that wrong assumption. > > But do you agree that answering yes/no questions should be allowed anytime > regardless of the value of enable-recursive-minibuffers? Yes, I think so. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Nov 2019 19:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Juri Linkov Cc: michael_heerdegen@web.de, rudalics@gmx.at, 17272@debbugs.gnu.org, joaotavora@gmail.com, 19064@debbugs.gnu.org, larsi@gnus.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15745366216872 (code B ref 17272); Sat, 23 Nov 2019 19:17:01 +0000 Received: (at 17272) by debbugs.gnu.org; 23 Nov 2019 19:17:01 +0000 Received: from localhost ([127.0.0.1]:57869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYatw-0001mk-LS for submit@debbugs.gnu.org; Sat, 23 Nov 2019 14:17:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYatW-0001m3-NH; Sat, 23 Nov 2019 14:16:52 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iYatB-0007bA-Mk; Sat, 23 Nov 2019 14:16:13 -0500 Received: from [176.228.60.248] (port=4934 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iYat7-0007X3-0D; Sat, 23 Nov 2019 14:16:09 -0500 Date: Sat, 23 Nov 2019 21:16:07 +0200 Message-Id: <83blt2tnd4.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <8736ee78v6.fsf@mail.linkov.net> (message from Juri Linkov on Sat, 23 Nov 2019 20:56:13 +0200) References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> <6d3c4659-0ffc-a847-e5ff-0d7cff73cbcd@gmx.at> <871ru0lxvj.fsf@mail.linkov.net> <30ac04db-fa08-ffe6-f517-36b2b3815b1d@gmx.at> <8736ee78v6.fsf@mail.linkov.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Date: Sat, 23 Nov 2019 20:56:13 +0200 > Cc: Michael Heerdegen , > Lars Ingebrigtsen , 19064@debbugs.gnu.org, > 17272@debbugs.gnu.org, > João Távora > > > + specbind (Qenable_recursive_minibuffers, Qt); > > > > then? > > It seems this is like unwind-protect? No, it's like let-binding. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Nov 2019 22:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157454786124039 (code B ref 17272); Sat, 23 Nov 2019 22:25:02 +0000 Received: (at 17272) by debbugs.gnu.org; 23 Nov 2019 22:24:21 +0000 Received: from localhost ([127.0.0.1]:57925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYdpB-0006Fb-Lt for submit@debbugs.gnu.org; Sat, 23 Nov 2019 17:24:20 -0500 Received: from eastern.birch.relay.mailchannels.net ([23.83.209.55]:1151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iYdp6-0006FG-Ez; Sat, 23 Nov 2019 17:24:13 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 097336A1AB3; Sat, 23 Nov 2019 22:24:11 +0000 (UTC) Received: from pdx1-sub0-mail-a34.g.dreamhost.com (100-96-86-105.trex.outbound.svc.cluster.local [100.96.86.105]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 9280D6A1995; Sat, 23 Nov 2019 22:24:10 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a34.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sat, 23 Nov 2019 22:24:10 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Hysterical-Desert: 35e301f3130aebe7_1574547850841_1299729679 X-MC-Loop-Signature: 1574547850841:3696309583 X-MC-Ingress-Time: 1574547850841 Received: from pdx1-sub0-mail-a34.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a34.g.dreamhost.com (Postfix) with ESMTP id 5630984069; Sat, 23 Nov 2019 14:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=n/OJ35Fct7wihxkieSrLMiywGRI=; b= xtz8Ntek1PHKjayHarp4GD5L2uEOc1OJbmS4WO1gbkMgLG4Zxu1jQ1dGGNtYWroW ysFa5GTFoAKiKkA7E+xLwJVIWVvz8WsxYx/kvHzteNoLpu4//wa7nvvnT0O/JO+Q lZif4tO0LNw20f1QAgbFCUWH6ubu+7yqUl8wc37gEe8= Received: from mail.jurta.org (m91-129-105-73.cust.tele2.ee [91.129.105.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 74B4484068; Sat, 23 Nov 2019 14:24:03 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a34 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87y4chjdop.fsf@gnus.org> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <878sobqxb4.fsf@mail.linkov.net> Date: Sat, 23 Nov 2019 23:54:01 +0200 In-Reply-To: <878sobqxb4.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 20 Nov 2019 00:28:15 +0200") Message-ID: <87h82u5rce.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >>> The variable name is =E2=80=98message-in-echo-area=E2=80=99. After a= little testing, >>> it seems to handle all such cases well: >> >> I have not tested the patch, but it looks good to me. > > Actually this patch needs more testing. I found already > two cases that might be annoying. Better to anticipate > a possible angry reaction and fix these cases in advance. After more testing, at least all noticed problems are fixed with this patch (it also reverts previous commits that added minibuffer-message and that is not needed anymore): --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=message-in-echo-area.patch diff --git a/lisp/autorevert.el b/lisp/autorevert.el index 079750a3f6..9275513c8d 100644 --- a/lisp/autorevert.el +++ b/lisp/autorevert.el @@ -815,8 +815,7 @@ auto-revert-handler (when revert (when (and auto-revert-verbose (not (eq revert 'fast))) - (with-current-buffer (window-buffer (old-selected-window)) - (minibuffer-message "Reverting buffer `%s'." (buffer-name)))) + (message "Reverting buffer `%s'." (buffer-name))) ;; If point (or a window point) is at the end of the buffer, we ;; want to keep it at the end after reverting. This allows one ;; to tail a file. diff --git a/lisp/isearch.el b/lisp/isearch.el index 4f3342782d..1705b050b5 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -2011,7 +2011,7 @@ isearch-message-properties (defun isearch--momentary-message (string) "Print STRING at the end of the isearch prompt for 1 second." (let ((message-log-max nil)) - (message "%s%s%s" + (message-in-echo-area "%s%s%s" (isearch-message-prefix nil isearch-nonincremental) isearch-message (apply #'propertize (format " [%s]" string) @@ -3168,7 +3170,7 @@ isearch-message (isearch-message-prefix ellipsis isearch-nonincremental) m (isearch-message-suffix c-q-hack))) - (if c-q-hack m (let ((message-log-max nil)) (message "%s" m))))) + (if c-q-hack m (let ((message-log-max nil)) (message-in-echo-area "%s" m))))) (defun isearch--describe-regexp-mode (regexp-function &optional space-before) "Make a string for describing REGEXP-FUNCTION. diff --git a/lisp/man.el b/lisp/man.el index ce01fdc805..beec2e616f 100644 --- a/lisp/man.el +++ b/lisp/man.el @@ -1474,7 +1474,7 @@ Man-bgproc-sentinel (kill-buffer Man-buffer))) (when message - (minibuffer-message "%s" message))))) + (message "%s" message))))) (defun Man-page-from-arguments (args) ;; Skip arguments and only print the page name. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index ee3d0095a9..7c87a18273 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -712,16 +712,16 @@ minibuffer-message (progn (if args (apply #'message message args) - (message "%s" message)) + (message-in-echo-area "%s" message)) (prog1 (sit-for (or minibuffer-message-timeout 1000000)) - (message nil))) + (message-in-echo-area nil))) ;; Record message in the *Messages* buffer (let ((inhibit-message t)) (if args (apply #'message message args) - (message "%s" message))) + (message-in-echo-area "%s" message))) ;; Clear out any old echo-area message to make way for our new thing. - (message nil) + (message-in-echo-area nil) (setq message (if (and (null args) (string-match-p "\\` *\\[.+\\]\\'" message)) ;; Make sure we can put-text-property. @@ -1838,7 +1838,7 @@ completion--done (defun minibuffer-completion-help (&optional start end) "Display a list of possible completions of the current minibuffer contents." (interactive) - (message "Making completion list...") + (message-in-echo-area "Making completion list...") (let* ((start (or start (minibuffer-prompt-end))) (end (or end (point-max))) (string (buffer-substring start end)) @@ -1849,7 +1849,7 @@ minibuffer-completion-help minibuffer-completion-predicate (- (point) start) md))) - (message nil) + (message-in-echo-area nil) (if (or (null completions) (and (not (consp (cdr completions))) (equal (car completions) string))) diff --git a/lisp/subr.el b/lisp/subr.el index 20daed623f..fae06399ef 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -4620,9 +4620,10 @@ do-after-load-evaluation byte-compile-current-file byte-compile-root-dir))) (byte-compile-warn "%s" msg)) - (run-with-idle-timer 0 nil + (run-with-timer 0 nil (lambda (msg) - (minibuffer-message "%s" msg)) + (discard-input) + (message "%s" msg)) msg))))) ;; Finally, run any other hook. diff --git a/src/editfns.c b/src/editfns.c index 8fc866d391..650dc6d4ca 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -2875,8 +2875,57 @@ accent (\\=`) and apostrophe (\\=') are special in the format; see any existing message; this lets the minibuffer contents show. See also `current-message'. +When the variable `message-in-echo-area' is non-nil, use the function +`message-in-echo-area' to display the message in the echo area. +Otherwise, when the minibuffer is active, use `minibuffer-message' +to temporarily display the message at the end of the minibuffer. + usage: (message FORMAT-STRING &rest ARGS) */) (ptrdiff_t nargs, Lisp_Object *args) +{ + if (NILP (Vmessage_in_echo_area) + && !inhibit_message + && !(NILP (args[0]) || (STRINGP (args[0]) && SBYTES (args[0]) == 0)) + && WINDOW_LIVE_P (Fold_selected_window ()) + && BUFFERP (Fwindow_buffer (Fold_selected_window ())) + && !NILP (Fminibufferp (Fwindow_buffer (Fold_selected_window ())))) + { + ptrdiff_t count = SPECPDL_INDEX (); + + /* Avoid possible recursion. */ + specbind (Qmessage_in_echo_area, Qt); + + record_unwind_current_buffer (); + Fset_buffer (Fwindow_buffer (Fold_selected_window ())); + + return unbind_to (count, CALLN (Fapply, intern ("minibuffer-message"), + Flist (nargs, args))); + } + else + return Fmessage_in_echo_area (nargs, args); +} + +DEFUN ("message-in-echo-area", Fmessage_in_echo_area, Smessage_in_echo_area, 1, MANY, 0, + doc: /* Display a message at the bottom of the screen. +The message also goes into the `*Messages*' buffer, if `message-log-max' +is non-nil. (In keyboard macros, that's all it does.) +Return the message. + +In batch mode, the message is printed to the standard error stream, +followed by a newline. + +The first argument is a format control string, and the rest are data +to be formatted under control of the string. Percent sign (%), grave +accent (\\=`) and apostrophe (\\=') are special in the format; see +`format-message' for details. To display STRING without special +treatment, use (message-in-echo-area "%s" STRING). + +If the first argument is nil or the empty string, the function clears +any existing message; this lets the minibuffer contents show. See +also `current-message'. + +usage: (message-in-echo-area FORMAT-STRING &rest ARGS) */) + (ptrdiff_t nargs, Lisp_Object *args) { if (NILP (args[0]) || (STRINGP (args[0]) @@ -4520,6 +4569,11 @@ syms_of_editfns (void) it to be non-nil. */); binary_as_unsigned = false; + DEFVAR_LISP ("message-in-echo-area", Vmessage_in_echo_area, + doc: /* Non-nil means overwrite the minibuffer with a message in the echo area. */); + Vmessage_in_echo_area = Qnil; + DEFSYM (Qmessage_in_echo_area, "message-in-echo-area"); + defsubr (&Spropertize); defsubr (&Schar_equal); defsubr (&Sgoto_char); @@ -4594,6 +4648,7 @@ syms_of_editfns (void) defsubr (&Semacs_pid); defsubr (&Ssystem_name); defsubr (&Smessage); + defsubr (&Smessage_in_echo_area); defsubr (&Smessage_box); defsubr (&Smessage_or_box); defsubr (&Scurrent_message); --=-=-=-- From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Nov 2019 23:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Eli Zaretskii Cc: michael_heerdegen@web.de, larsi@gnus.org, 17272@debbugs.gnu.org, joaotavora@gmail.com, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15748104297210 (code B ref 17272); Tue, 26 Nov 2019 23:21:01 +0000 Received: (at 17272) by debbugs.gnu.org; 26 Nov 2019 23:20:29 +0000 Received: from localhost ([127.0.0.1]:53172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZk8D-0001sD-LK for submit@debbugs.gnu.org; Tue, 26 Nov 2019 18:20:29 -0500 Received: from cheetah.birch.relay.mailchannels.net ([23.83.209.34]:25366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZk8B-0001s1-W3; Tue, 26 Nov 2019 18:20:28 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A0C645E1DBC; Tue, 26 Nov 2019 23:20:26 +0000 (UTC) Received: from pdx1-sub0-mail-a89.g.dreamhost.com (100-96-88-70.trex.outbound.svc.cluster.local [100.96.88.70]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id ECD1B5E2573; Tue, 26 Nov 2019 23:20:25 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a89.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 26 Nov 2019 23:20:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Sponge-Imminent: 55ab986a04669c1d_1574810426260_4004848891 X-MC-Loop-Signature: 1574810426260:3843667634 X-MC-Ingress-Time: 1574810426260 Received: from pdx1-sub0-mail-a89.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTP id A4A35A4160; Tue, 26 Nov 2019 15:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=MT5/u1pdO6BCb1Czl24k3fyAous=; b= p1zCat/IrJnnU5cwSDmFn/0M+zz3ISdRatrGFoVRnU7+VSD0koSh3QXJ42FT9z6v yzmKZbNUnbSjU26yHC+s/BMY/yAYZwcAdPzGtDj9uhrGtKeWUV/Y37LgIOSxowEg nY6H6ffwCinyOlzlmtznISGVxAT9Gnafg0N1FbGZNTE= Received: from mail.jurta.org (m91-129-96-42.cust.tele2.ee [91.129.96.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 96A6FA4164; Tue, 26 Nov 2019 15:20:16 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a89 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> <878soacdur.fsf@gmail.com> <878so8lxyx.fsf@mail.linkov.net> <83r220wduu.fsf@gnu.org> <87tv6u5tuu.fsf@mail.linkov.net> <83eexytnf9.fsf@gnu.org> Date: Wed, 27 Nov 2019 01:18:30 +0200 In-Reply-To: <83eexytnf9.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 23 Nov 2019 21:14:50 +0200") Message-ID: <878so21b21.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> > I don't, FWIW. So please don't build any revolutionary UI changes on >> > that wrong assumption. >> >> But do you agree that answering yes/no questions should be allowed anytime >> regardless of the value of enable-recursive-minibuffers? > > Yes, I think so. So I installed the patch that allows it. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Nov 2019 23:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed To: Lars Ingebrigtsen Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15748119499791 (code B ref 17272); Tue, 26 Nov 2019 23:46:02 +0000 Received: (at 17272) by debbugs.gnu.org; 26 Nov 2019 23:45:49 +0000 Received: from localhost ([127.0.0.1]:53190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZkWj-0002Xq-Bj for submit@debbugs.gnu.org; Tue, 26 Nov 2019 18:45:49 -0500 Received: from bisque.elm.relay.mailchannels.net ([23.83.212.18]:59073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZkWh-0002Xb-6v; Tue, 26 Nov 2019 18:45:48 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AFEBB3C03FC; Tue, 26 Nov 2019 23:45:45 +0000 (UTC) Received: from pdx1-sub0-mail-a89.g.dreamhost.com (100-96-196-51.trex.outbound.svc.cluster.local [100.96.196.51]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3C6DE3C0E2A; Tue, 26 Nov 2019 23:45:45 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a89.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 26 Nov 2019 23:45:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Abortive-Thoughtful: 3490123a313364fd_1574811945508_3336283732 X-MC-Loop-Signature: 1574811945508:3337926579 X-MC-Ingress-Time: 1574811945508 Received: from pdx1-sub0-mail-a89.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTP id CA6D3A4162; Tue, 26 Nov 2019 15:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=CGzP40 4HivKj6lLsOsaPEa5xALQ=; b=xK3zoYuU+Aim253W43ZBtxLFI3I3Rk8vpll9ft 5bUCUcaQY33/8Wn2J/KO/vrQoNBkgIoZwm54A07NhP7fFkVVhIxvGTr3Vaz6JHip 5Y/9fuK16OCerf2Q5Knzb6Fiw2rSlJM4zBn0EQYujZ42QAo0G3qcFPxtN01UWuE+ oyd74= Received: from mail.jurta.org (m91-129-96-42.cust.tele2.ee [91.129.96.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTPSA id DEAB4A4160; Tue, 26 Nov 2019 15:45:36 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a89 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87o8ys3131.fsf@gnus.org> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <878sobqxb4.fsf@mail.linkov.net> <87h82u5rce.fsf@mail.linkov.net> Date: Wed, 27 Nov 2019 01:44:49 +0200 In-Reply-To: <87h82u5rce.fsf@mail.linkov.net> (Juri Linkov's message of "Sat, 23 Nov 2019 23:54:01 +0200") Message-ID: <87k17myzgu.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 17272 fixed tags 19064 fixed close 17272 27.0.50 close 19064 27.0.50 quit >>>> The variable name is =E2=80=98message-in-echo-area=E2=80=99. After = a little testing, >>>> it seems to handle all such cases well: >>> >>> I have not tested the patch, but it looks good to me. >> >> Actually this patch needs more testing. I found already >> two cases that might be annoying. Better to anticipate >> a possible angry reaction and fix these cases in advance. > > After more testing, at least all noticed problems are fixed > with this patch (it also reverts previous commits that > added minibuffer-message and that is not needed anymore): This patch is installed now, and the bug report is closed. It also fixed long-standing annoyance of using query-replace in the minib= uffer. Previously the query-replace prompt completely obscured the replaced text= . Now the query-replace prompt is displayed at the end of the minibuffer, so the replaced text is visible in the minibuffer. The requested NEWS and Info manual changes were installed as well: diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi index ddbae40ac9..b5990130c6 100644 --- a/doc/lispref/display.texi +++ b/doc/lispref/display.texi @@ -276,11 +276,13 @@ Displaying Messages When @code{inhibit-message} is non-@code{nil}, no message will be displa= yed in the echo area, it will only be logged to @samp{*Messages*}. =20 +If the minibuffer is active, it uses the @code{minibuffer-message} +function to display the message temporarily at the end of the +minibuffer (@pxref{Minibuffer Misc}). + If @var{format-string} is @code{nil} or the empty string, @code{message} clears the echo area; if the echo area has been -expanded automatically, this brings it back to its normal size. If -the minibuffer is active, this brings the minibuffer contents back -onto the screen immediately. +expanded automatically, this brings it back to its normal size. =20 @example @group diff --git a/etc/NEWS b/etc/NEWS index 7a51106add..48ad1a299a 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -724,6 +724,10 @@ the minibuffer. If non-nil, point will move to the = end of the prompt *** Minibuffer now uses 'minibuffer-message' to display error messages at the end of the active minibuffer. =20 ++++ +*** The function 'message' now displays the message at the end of the mi= nibuffer +when the minibuffer is active. + +++ *** 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer. =20 From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Nov 2019 00:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed fixed To: Juri Linkov , Eli Zaretskii Cc: michael_heerdegen@web.de, joaotavora@gmail.com, larsi@gnus.org, 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157481572123469 (code B ref 17272); Wed, 27 Nov 2019 00:49:02 +0000 Received: (at 17272) by debbugs.gnu.org; 27 Nov 2019 00:48:41 +0000 Received: from localhost ([127.0.0.1]:53231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZlVZ-00066O-By for submit@debbugs.gnu.org; Tue, 26 Nov 2019 19:48:41 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:48982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZlVU-00065z-S6; Tue, 26 Nov 2019 19:48:38 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAR0j8Ho151643; Wed, 27 Nov 2019 00:48:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=pSJkUAElM8ObeYDbUuDgNiFACmFd/Nv1IPJdielRHEY=; b=oCVXszrSwyFq7JsmvC5nnTkt6iXF8QSzvRUwX/N7l7XIP3ezv6XLVVOqVWUzHhE5RxP9 TWJw5SRwd9TlCxvVsXM83YAUYmT3QUAlVyn+Q2Rg+F+TO+D0kkf32OHvGWMeStfT9a6W NmFbQrdO0SrhXXcaTBjMfB5idI8BtOae3KnpSwplehJBd3OZJxpTL1AmwjCPctWFl85u v9IlaxC1Js8U14arWaIHWV1qBPpZIIy2JXoq0GXYVzdkZEXSLqA7V/DkmuohV697ACX4 rDIancZMtqBAHvwIY98d4eisqwotsFWfR8AolKH9lJLtdIZVvLOVCJ4biH9ahaRmTQUU iQ== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2wev6ua4pw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Nov 2019 00:48:30 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAR0hjFt137323; Wed, 27 Nov 2019 00:46:29 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 2wh0rf0epe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Nov 2019 00:46:29 +0000 Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAR0kPQu009086; Wed, 27 Nov 2019 00:46:26 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 26 Nov 2019 16:46:24 -0800 (PST) From: Drew Adams References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <877e3vqx9r.fsf@mail.linkov.net> <87v9reqk6o.fsf@mail.linkov.net> <878soacdur.fsf@gmail.com> <878so8lxyx.fsf@mail.linkov.net> <83r220wduu.fsf@gnu.org> <87tv6u5tuu.fsf@mail.linkov.net> <83eexytnf9.fsf@gnu.org> <878so21b21.fsf@mail.linkov.net> In-Reply-To: <878so21b21.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4927.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9453 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=976 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911270003 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9453 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911270003 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > So I installed the patch that allows it. FWIW and FTR, as the filer of bug #19064, and as I expressed several times in this thread, I strongly object to the changes that have now been made. All of what I said has been ignored. Unfortunate. This is not at all a good fix for the problem reported. And it imposes a very bad behavior more generally - beyond the problem cited. `message' and `minibuffer-message', i.e., writing to the echo area and to the minibuffer, both have their uses when the minibuffer is active. And `y-or-n-p' should continue to use `read-key', not the minibuffer. And `enable-recursive-minibuffers' should not be turned on automatically by `yes-or-no-p'. Instead, if the function calling `yes-or-no-p' has not turned it on then an error should be raised when `yes-or-no-p' tries to use the minibuffer. I'm not aware of any part of this "fix" that's acceptable. From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Nov 2019 11:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed fixed To: Juri Linkov Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157485575727133 (code B ref 17272); Wed, 27 Nov 2019 11:56:01 +0000 Received: (at 17272) by debbugs.gnu.org; 27 Nov 2019 11:55:57 +0000 Received: from localhost ([127.0.0.1]:53527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZvvJ-00073U-88 for submit@debbugs.gnu.org; Wed, 27 Nov 2019 06:55:57 -0500 Received: from quimby.gnus.org ([95.216.78.240]:55036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iZvvH-000739-6k; Wed, 27 Nov 2019 06:55:55 -0500 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iZvv8-0001GW-Rd; Wed, 27 Nov 2019 12:55:49 +0100 From: Lars Ingebrigtsen References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <875zjx6hs6.fsf@mail.linkov.net> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <878sobqxb4.fsf@mail.linkov.net> <87h82u5rce.fsf@mail.linkov.net> <87k17myzgu.fsf@mail.linkov.net> Date: Wed, 27 Nov 2019 12:55:45 +0100 In-Reply-To: <87k17myzgu.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 27 Nov 2019 01:44:49 +0200") Message-ID: <87fti9fs8u.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > This patch is installed now, and the bug report is closed. Great! Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ingebrigtsen.no] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Juri Linkov writes: > This patch is installed now, and the bug report is closed. Great! I wonder whether read-multiple-choice should get the same treatment? It currently uses read-event. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Tue Jun 17 22:30:33 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Nov 2019 23:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17272 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed fixed To: Lars Ingebrigtsen Cc: Michael Heerdegen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157498462321316 (code B ref 17272); Thu, 28 Nov 2019 23:44:02 +0000 Received: (at 17272) by debbugs.gnu.org; 28 Nov 2019 23:43:43 +0000 Received: from localhost ([127.0.0.1]:59250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iaTRn-0005Xi-9Q for submit@debbugs.gnu.org; Thu, 28 Nov 2019 18:43:43 -0500 Received: from antelope.elm.relay.mailchannels.net ([23.83.212.4]:24045) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iaTRl-0005XU-1v; Thu, 28 Nov 2019 18:43:42 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 77C8AE0F6D; Thu, 28 Nov 2019 23:43:38 +0000 (UTC) Received: from pdx1-sub0-mail-a33.g.dreamhost.com (100-96-86-105.trex.outbound.svc.cluster.local [100.96.86.105]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D7A91E0E9E; Thu, 28 Nov 2019 23:43:37 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a33.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 28 Nov 2019 23:43:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Hook-Trail: 2de68cc459fee023_1574984618144_2017576286 X-MC-Loop-Signature: 1574984618144:185799482 X-MC-Ingress-Time: 1574984618144 Received: from pdx1-sub0-mail-a33.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTP id E5FCE7FC51; Thu, 28 Nov 2019 15:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=U+4/1cSNMrsb2JjprrODiipnVdw=; b= NpkcKB8W0uDV6Bw4+WKp6Lx/t/qcAx3y02BZO+JzpAx0S3azn1g7jXnsRe+IkT+n yYUGJTqQoJrGooE5j33if4o6iznwCUuQEm7LzXom5+67lkXjlXhqi74HYHDJNxlh kuhVIHOlvJ2IupiYH9pPrNuG2sqDbjJjonJc9u/Ny6Y= Received: from mail.jurta.org (m91-129-96-42.cust.tele2.ee [91.129.96.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 15B2B7FC5E; Thu, 28 Nov 2019 15:43:26 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a33 From: Juri Linkov Organization: LINKOV.NET References: <8ea0a3fa-5169-4493-bd54-3ebe47836a35@default> <87sgmy3x22.fsf@gnus.org> <871rugbqmy.fsf@mail.linkov.net> <87d0dxyh7z.fsf@gnus.org> <53c55db5-d623-4946-af2e-d141e7bc7acd@default> <87sgmrpir5.fsf@web.de> <87mucya2a7.fsf@web.de> <87mucy4cb2.fsf@web.de> <621b98dc-0fe9-4eef-9e11-7580fb446e97@default> <87k1822ocn.fsf@web.de> <87lfsfmtk0.fsf@mail.linkov.net> <874kz3gibu.fsf@gnus.org> <87bltaw3xz.fsf@mail.linkov.net> <87r224x54p.fsf@mail.linkov.net> <87v9rgnv0o.fsf@gnus.org> <878sobqxb4.fsf@mail.linkov.net> <87h82u5rce.fsf@mail.linkov.net> <87k17myzgu.fsf@mail.linkov.net> <87fti9fs8u.fsf@gnus.org> Date: Fri, 29 Nov 2019 00:45:46 +0200 In-Reply-To: <87fti9fs8u.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 27 Nov 2019 12:55:45 +0100") Message-ID: <8736e77h7p.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> This patch is installed now, and the bug report is closed. > > Great! > > I wonder whether read-multiple-choice should get the same treatment? It > currently uses read-event. There are many other functions waiting for the same treatment. Some examples that I noticed recently: map-y-or-n-p, ask-user-about-lock.