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#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it Date: Wed, 13 Nov 2019 15:24:51 -0800 (PST) Message-ID: 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> 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="135995"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Lars Ingebrigtsen , Juri Linkov , 17272@debbugs.gnu.org, 19064@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 14 00:26:14 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 1iV21d-000ZE8-SW for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Nov 2019 00:26:14 +0100 Original-Received: from localhost ([::1]:52320 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iV21c-0007K4-I7 for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Nov 2019 18:26:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34241) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iV21U-0007Jp-0u for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2019 18:26:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iV21S-0003Vn-Jz for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2019 18:26:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51640) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iV21S-0003VM-Cb for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2019 18:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iV21S-0005ke-45 for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2019 18:26: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: 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 Original-Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.157368751422051 (code B ref 17272); Wed, 13 Nov 2019 23:26:02 +0000 Original-Received: (at 17272) by debbugs.gnu.org; 13 Nov 2019 23:25:14 +0000 Original-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 Original-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 Original-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== Original-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 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 xADNGHZ9107371; Wed, 13 Nov 2019 23:24:56 GMT Original-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 Original-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 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)] 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-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:171516 Archived-At: > 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.