From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Date: Sun, 17 Nov 2019 15:54:20 -0800 (PST) Message-ID: <4ffe34ef-019e-49bf-b2b0-76ee9ce88fcf@default> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="253500"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Michael Heerdegen , Lars Ingebrigtsen , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 18 00:55:20 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iWUNz-0013ni-Fb for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Nov 2019 00:55:19 +0100 Original-Received: from localhost ([::1]:57152 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWUNx-00012y-T8 for geb-bug-gnu-emacs@m.gmane.org; Sun, 17 Nov 2019 18:55:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52675) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWUNl-00010G-UX for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2019 18:55:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWUNi-0006nB-Qc for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2019 18:55:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34115) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iWUNi-0006n3-Nk for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2019 18:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iWUNi-0007wW-JK for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2019 18:55:02 -0500 X-Loop: help-debbugs@gnu.org 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 19064 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 19064-submit@debbugs.gnu.org id=B19064.157403488330492 (code B ref 19064); Sun, 17 Nov 2019 23:55:02 +0000 Original-Received: (at 19064) by debbugs.gnu.org; 17 Nov 2019 23:54:43 +0000 Original-Received: from localhost ([127.0.0.1]:42933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWUNO-0007vj-Rd for submit@debbugs.gnu.org; Sun, 17 Nov 2019 18:54:43 -0500 Original-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 Original-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== Original-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 Original-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 Original-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 Original-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 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)] 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:171880 Archived-At: > > 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.