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: Tue, 12 Nov 2019 15:23:04 -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> <87tv78g2jw.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="233145"; 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 Wed Nov 13 00:25:11 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 1iUfX5-000yXl-6l for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Nov 2019 00:25:11 +0100 Original-Received: from localhost ([::1]:40404 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUfX4-0002FO-1j for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2019 18:25:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46815) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUfWx-0002FG-Mx for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 18:25:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iUfWw-0002jw-7V for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 18:25:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49794) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iUfWw-0002js-3J for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 18:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iUfWv-00011Z-UU for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 18:25:01 -0500 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 17272-submit@debbugs.gnu.org id=B17272.15736010663892 (code B ref 17272); Tue, 12 Nov 2019 23:25:01 +0000 Original-Received: (at 17272) by debbugs.gnu.org; 12 Nov 2019 23:24:26 +0000 Original-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 Original-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 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 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== Original-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 Original-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 Original-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 Original-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 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)] 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-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:171478 Archived-At: > > `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.