From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer? Date: Tue, 5 May 2020 11:10:39 -0700 (PDT) Message-ID: <1b1632e1-2669-44c3-b6c1-1d8da519a91b@default> References: <85imhah1kt.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="74058"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41087@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 05 20:11:38 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jW22b-000J8L-LU for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 May 2020 20:11:37 +0200 Original-Received: from localhost ([::1]:48026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jW22a-0007A5-N6 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 May 2020 14:11:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50418) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jW223-0006jt-4r for bug-gnu-emacs@gnu.org; Tue, 05 May 2020 14:11:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54080) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jW222-0008SG-7G for bug-gnu-emacs@gnu.org; Tue, 05 May 2020 14:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jW222-0006wE-2k for bug-gnu-emacs@gnu.org; Tue, 05 May 2020 14:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 May 2020 18:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41087 X-GNU-PR-Package: emacs Original-Received: via spool by 41087-submit@debbugs.gnu.org id=B41087.158870225126636 (code B ref 41087); Tue, 05 May 2020 18:11:02 +0000 Original-Received: (at 41087) by debbugs.gnu.org; 5 May 2020 18:10:51 +0000 Original-Received: from localhost ([127.0.0.1]:37392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW21r-0006vX-Ds for submit@debbugs.gnu.org; Tue, 05 May 2020 14:10:51 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:34946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW21o-0006v9-C3 for 41087@debbugs.gnu.org; Tue, 05 May 2020 14:10:49 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 045IAGgu071444; Tue, 5 May 2020 18:10: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-2020-01-29; bh=NVJgkSgMscKlJvfqKX30Tgn+usEzumSpirJuKsoAv+s=; b=ezgszr3Q4v6aHxlGYD0ovCKl80ogS6+RUZW/BgPymcsHgwcp0/9E/d3yAN+9do/RISr/ NsRr/BTA+VFvW4OBwIup9PFTGz3umlveEtW6L6xVGZCOptOdXa/A3SPgWAcWwGme1S5I 62+q5llUe+kpGhviEKTANO81/snYZN7c46XcGMOvPiwFWB+AmVPWyatk++5ie0fuM4Ia qXpEU9rvL8Fr/IpUX1VU2KufY4ztpTp/RUGREGt4V6OOUeGID4JpAh8Q+92UzbnKQpnI QB4ja9ml6vVDAwsW5SvYiSa0GwxSOt9q32kSpz9tvG8S4V6gTj4qWqMU0SrOxtUswSh9 5A== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 30s09r6cfs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 05 May 2020 18:10:42 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 045IA4Dm152507; Tue, 5 May 2020 18:10:42 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 30sjk08bqj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 05 May 2020 18:10:42 +0000 Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 045IAe84017420; Tue, 5 May 2020 18:10:41 GMT In-Reply-To: <85imhah1kt.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9612 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 phishscore=0 bulkscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005050138 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9612 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 lowpriorityscore=0 spamscore=0 adultscore=0 clxscore=1015 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005050138 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:179757 Archived-At: > > I think that some of the problems come from the changes to minibuffer > > and echo-area behavior. Regardless of whether that is the case, I > > want to undo those changes. Is there an option for that? (I hope so.) > > If not, what changes do I need to make from Lisp, to get back the prior > > behavior? >=20 > Here's my guesses (none tested) about each item you list. Of course, > these particular may or may not be the cause of your troubles (whatever > they are). Thanks, Noam, for going to all the trouble you did. I'll try them, at least once I get past the main problem of minibuffer input-focus loss. > > *** A new user option, 'minibuffer-beginning-of-buffer-movement', has > > been introduced to allow controlling how the 'M-<' command works in > > the minibuffer. If non-nil, point will move to the end of the prompt > > (if point is after the end of the prompt). >=20 > AFAICT, this one is already disabled by default (i.e., > minibuffer-beginning-of-buffer-movement is nil by default). I doubt that's related. But OK. BTW, why a user option for that? Why not just bind `M-<' to a different command in the minibuffer maps? (Doesn't matter to me. Just wondering.) > > *** When the minibuffer is active, echo-area messages are displayed > > at the end of the minibuffer instead of hiding the minibuffer by the > > echo area display. The new user option 'minibuffer-message-clear-timeo= ut' > > controls how messages displayed in this situation are removed from > > the minibuffer. I saw that. I'll take a closer look, but a priori I'm not interested in controlling _HOW_ msgs are displayed in this situation (the situation being that they're shown automatically, at the end of the minibuffer). I'm interested in not having that situation at all - not how they're displayed at the end of the minibuffer but how to not have that happen at all. I want the old behavior (since Emacs Day One). > (setq set-message-function nil) > (setq clear-message-function nil) Thanks; that's probably it. If it is, I think NEWS should say explicitly that setting these to nil removes the new behavior of "When the minibuffer is active, echo-area messages are ...". That is, section "** Minibuffer" should tell you how to revert to the previous Emacs behavior. In particular, where it says this: "Minibuffer now uses 'minibuffer-message' to display error messages at the end of the active minibuffer." it should tell you how to disable that new behavior. (And isn't it about all echo-area messages, not just "error messages"?) > New variable set-message-function to show message at the end of the > minibuffer >=20 > https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git > /commit/?id=3D485b423e8f0df2711a850be7f254665f64ab0bdb__;!!GqivPVa7Brio!L > G_VudrPxJ8CU6VhuvBVOW0-LlUGAuEG9l125HX6QQ9ReoJg1Gg3NCe430S9TyOY$ Great; thanks. It would be good for the NEWS mention of that variable to link to the manual explanation. > > *** Minibuffer now uses 'minibuffer-message' to display error > > messages at the end of the active minibuffer. >=20 > (remove-hook 'minibuffer-setup-hook 'minibuffer-error-initialize) Good. Pity there's not a simple user option to revert the new behavior. And it would be good for NEWS to explicitly show all such code for reverting this echo-area msgs change in one place. > User-friendly display of error messages at the end of minibuffer >=20 > https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git > /commit/?id=3D2aae063055283ee64ecf339c812a1fe6d1cb106e__;!!GqivPVa7Brio!L > G_VudrPxJ8CU6VhuvBVOW0-LlUGAuEG9l125HX6QQ9ReoJg1Gg3NCe43zpNUlIi$ Thanks. I do recall lots of traffic in the bug list about Juri's proposed changes. I expressed my disagreement in detail at the time, to no avail. But if it's easy enough to revert them all then that's great, and all one can ask for, I guess. I do think the doc, and NEWS, could help by clearly saying how to revert the changes. Maybe it does so sufficiently; I haven't studied it. > >=20 > > +++ > > *** 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer. >=20 > You'd have to evaluate the old lisp code of y-or-n-p. >=20 > [a26a8cc1c85]: 2019-11-10 00:04:13 +0200 > 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer > (bug#38076) >=20 > https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git > /commit/?id=3Da26a8cc1c85f29fb11209c16d53a8ae4e4ab7ced__;!!GqivPVa7Brio!L > G_VudrPxJ8CU6VhuvBVOW0-LlUGAuEG9l125HX6QQ9ReoJg1Gg3NCe438q6MbCM$ >=20 > > --- > > *** Some commands that previously used 'read-char-choice' now read > > a character using the minibuffer by 'read-char-from-minibuffer'. >=20 > You'd have to evaluate the old lisp of files--ask-user-about-large-file > and hack-local-variables-confirm. >=20 > [027f218ad22]: 2019-11-10 00:32:09 +0200 > hack-local-variables-confirm uses the minibuffer to read answer > (bug#38076) >=20 > https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git > /commit/?id=3D027f218ad227c3966df94b22566c2e89a307362d__;!!GqivPVa7Brio!L > G_VudrPxJ8CU6VhuvBVOW0-LlUGAuEG9l125HX6QQ9ReoJg1Gg3NCe436x220-7$ >=20