From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change Date: Tue, 10 Dec 2019 05:36:24 +0200 Message-ID: <83tv68c0nb.fsf@gnu.org> References: <8736e3vve8.fsf@gmx.net> <8736e2coyv.fsf@mail.linkov.net> <83y2vujd0y.fsf@gnu.org> <87blspm0sm.fsf@mail.linkov.net> <837e3ckbem.fsf@gnu.org> <871rtjn0kt.fsf@mail.linkov.net> <83lfrrigj8.fsf@gnu.org> <87eexiqps5.fsf@mail.linkov.net> <83lfrphp94.fsf@gnu.org> <87wob7g2jk.fsf@mail.linkov.net> <83k177ebs0.fsf@gnu.org> <87muc27prn.fsf@mail.linkov.net> <83tv6acgq5.fsf@gnu.org> <87eexdoygh.fsf@mail.linkov.net> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="34673"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38457@debbugs.gnu.org, stephen.berman@gmx.net To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 10 04:37: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 1ieWKk-0008nt-G1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 04:37:10 +0100 Original-Received: from localhost ([::1]:49838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieWKi-00071F-QC for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Dec 2019 22:37:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55935) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieWKd-000717-1C for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 22:37:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ieWKb-00012R-UJ for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 22:37:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48694) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ieWKb-00012N-RU for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 22:37:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ieWKb-0002se-PT for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 22:37:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Dec 2019 03:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38457 X-GNU-PR-Package: emacs Original-Received: via spool by 38457-submit@debbugs.gnu.org id=B38457.157594900711053 (code B ref 38457); Tue, 10 Dec 2019 03:37:01 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 10 Dec 2019 03:36:47 +0000 Original-Received: from localhost ([127.0.0.1]:54667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieWKN-0002sC-5E for submit@debbugs.gnu.org; Mon, 09 Dec 2019 22:36:47 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieWKK-0002rz-ML for 38457@debbugs.gnu.org; Mon, 09 Dec 2019 22:36:45 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45121) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ieWKE-0000vf-RW; Mon, 09 Dec 2019 22:36:38 -0500 Original-Received: from [176.228.60.248] (port=2407 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ieWKE-00013T-8L; Mon, 09 Dec 2019 22:36:38 -0500 In-reply-to: <87eexdoygh.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 10 Dec 2019 01:45:18 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:173131 Archived-At: > From: Juri Linkov > Cc: 38457@debbugs.gnu.org, stephen.berman@gmx.net > Date: Tue, 10 Dec 2019 01:45:18 +0200 > > > And the original bug reports definitely were about y-or-n-p. > > bug#34614 was not about y-or-n-p. It was about any command that uses > the minibuffer. I was talking about the 3 bug reports mentioned in the change's log. > > I don't see how this is a "hack" when it uses the same technique as > > your changes in 'message': checking a variable that is bound by other > > functions. The advantage of my proposal is that it makes the new > > functionality opt-in, so that any commands which need this could have > > it by simply binding a variable, and would otherwise maintain its old > > behavior, which was there for eons. > > Such variable already exists. It's called message-in-echo-area. > You can enable it in the release branch if you want. > But then please reopen bug#34614, bug#19064, bug#17272, bug#446. Sorry, I don't understand the proposal. How will this variable help if we leave the current code in 'message' as it is? And what do you mean by "enabling" message-in-echo-area? > > Type M-x, then press F5 => the debugger doesn't start, although the > > message appears that should have triggered the debugger. > > This is exactly the purpose of the pretest - you are testing a new feature > or a bug fix, then discover that some feature doesn't work, report it, > and the following patch implements the missing feature. I expect to see a lot of such problems, and consequently a lot of patches. More importantly, I expect quite a few of those to slip into the release. That's because minibuffer-message's behavior is very different from that of 'message', and these differences will bite us every turn for a long time. This is not the right way of fixing the problems with overwriting the prompts by messages. It will certainly prolong the pretest too much, and most probably leave some problems undiscovered and unsolved. > Looking at the recent log, there are many fixes in core functions > with potentially destabilizing changes still committed every day. > How fixes in minibuffer-message are different from other > more risky fixes in other core functions? They are much more risky because they are in an infrastructure used all over the place, and also because the method selected for displaying such messages by minibuffer-message changes the behavior in very significant ways, so it will certainly cause many unintended consequences. The patch below also changes the behavior of minibuffer-message wrt debug-on-message, doesn't it? If so, we cannot install it as shown. We must find a better solution for the original problems, or decide to postpone the solution till after Emacs 27. Please help me in this matter. Thanks.