From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: HaiJun Zhang Newsgroups: gmane.emacs.bugs Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change Date: Tue, 10 Dec 2019 15:19:37 +0800 Message-ID: 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> <83tv68c0nb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="5def470e_580bd78f_422" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="110419"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38457@debbugs.gnu.org, stephen.berman@gmx.net To: Juri Linkov , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 10 08:20: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 1ieZoi-000SaF-CY for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 08:20:20 +0100 Original-Received: from localhost ([::1]:51398 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieZog-0008CN-QF for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 02:20:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47063) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieZoS-00089k-AN for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 02:20:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ieZoQ-0000Ra-Iu for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 02:20:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48904) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ieZoQ-0000RI-9v for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 02:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ieZoQ-00054z-43 for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 02:20:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: HaiJun Zhang Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Dec 2019 07:20:02 +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.157596239819509 (code B ref 38457); Tue, 10 Dec 2019 07:20:02 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 10 Dec 2019 07:19:58 +0000 Original-Received: from localhost ([127.0.0.1]:54877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieZoM-00054a-9g for submit@debbugs.gnu.org; Tue, 10 Dec 2019 02:19:58 -0500 Original-Received: from mail-oln040092253096.outbound.protection.outlook.com ([40.92.253.96]:24803 helo=APC01-SG2-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieZoJ-00054J-PL for 38457@debbugs.gnu.org; Tue, 10 Dec 2019 02:19:57 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ABdluKNSYXQWnJZLfvX6jKvgnYeb/uvoPzlOXsW1Twe4iEBBaxpoAyHpRnUVzU/8BPFAAFXwUWt4b8wSc69LLq4onCCQwXEYblSaHv4mnT8n+H71FjyxzqMLCYjnOZutQNXYEBVi4/P6AQSv3sFkUOmE91udATimf2LiySNHAG8LZrMRCM+aT/JuRWTOtcp1KWnK8JCvaV+24BGEPMu60IDqSn1qO5Lymf0cSHos9+874un/Mbk8WIm4kIG7OgfZdQJDXMWHFJDKzjdpGIxweqCe6DyunoExaLa1lzjhDMe8BfFU+W6J8H835qn2f8eBrnGwHbkME1bzV9NPYhTxvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YDnJnvTN3HNGFlO94wFrmqAD4niBX/Cv1onVM0X4zOk=; b=Qv22vTZGeW28DgS3Ygc9PQoPJ+iEjCdSx5cr8drZucJCXuJYYiZSwgDDckbt5YDwoJao2WrBZTcFUyIy6HHMND1hnAR1BzTLgf4lK617Pdun7BLCQL2k6ntqeRq+hiTNsH5DhgPIX0aavu1PnTH6GY8UNcIYEmSi2NIxU93CFO6ecJbiQDuTnbL66UfBSAATek5bGDf5sRyJh9HtOS5TOyOuTLof/G4wgfW+NtXvs2joXvhzx7e301b1aB+xIf01rkT5hM8unBwDRnK8CN0REDE/VMFF8BpPsrawrrtIgTeulV1nJbz0oahLS5VWtsP5PrFo1sLi5I6NhxER6SSU6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=outlook.com; dmarc=pass action=none header.from=outlook.com; dkim=pass header.d=outlook.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YDnJnvTN3HNGFlO94wFrmqAD4niBX/Cv1onVM0X4zOk=; b=O953wv5oyFN5tEMfolTfQyTLFzFG68AdawnrwVW39yzz8kF2nw6Ire+2sFSHgVtVcVpv5SsUbRYDE1jftiuHSxvqkgzcqKqa8au2k9jJLQbrfYNrfipKPdjwhs7s0FUvXduvfYJ/cp9JeYFIfDSDtOo7wfB6GwFfu6gJwjlqnNKHJxRM5cSvLmUAJG5wZnXZ88kn0mKNPXacw6+996Qww2qktr/xxWKa2h4AJijdOJDuvBddC830wSznnHke/ApYItUeozbI5hOXZETX4UFwdhqlWJgoaK/38JGiszQ0Qlb8o/edoAHYYDT1TgxcGbArhNnKZSIy35E+XmQeZb6zzA== Original-Received: from SG2APC01FT042.eop-APC01.prod.protection.outlook.com (10.152.250.53) by SG2APC01HT237.eop-APC01.prod.protection.outlook.com (10.152.251.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.25; Tue, 10 Dec 2019 07:19:47 +0000 Original-Received: from PS1PR03MB3606.apcprd03.prod.outlook.com (10.152.250.55) by SG2APC01FT042.mail.protection.outlook.com (10.152.251.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.25 via Frontend Transport; Tue, 10 Dec 2019 07:19:47 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:C66E2833AD6FD30D461AEBACAC36EFFD97EDF7504E4E9F35B08551D50E03FDD1; UpperCasedChecksum:EBFE4E7958FCDC52C66FCF2653B0F5FC9EBF5CF575C4ADFC56B7C41EB5CB4BCD; SizeAsReceived:9143; Count:48 Original-Received: from PS1PR03MB3606.apcprd03.prod.outlook.com ([fe80::b05a:28e4:205a:d7d4]) by PS1PR03MB3606.apcprd03.prod.outlook.com ([fe80::b05a:28e4:205a:d7d4%5]) with mapi id 15.20.2538.012; Tue, 10 Dec 2019 07:19:47 +0000 In-Reply-To: <83tv68c0nb.fsf@gnu.org> X-Readdle-Message-ID: dfa4034b-22ce-4782-b042-48b5923fab6e@Spark X-ClientProxiedBy: HK2PR02CA0130.apcprd02.prod.outlook.com (2603:1096:202:16::14) To PS1PR03MB3606.apcprd03.prod.outlook.com (2603:1096:803:4e::17) X-Microsoft-Original-Message-ID: Original-Received: from [192.168.1.103] (1.199.222.221) by HK2PR02CA0130.apcprd02.prod.outlook.com (2603:1096:202:16::14) with Microsoft SMTP Server (version=TLS1_2, cipher=) via Frontend Transport; Tue, 10 Dec 2019 07:19:45 +0000 X-Readdle-Message-ID: dfa4034b-22ce-4782-b042-48b5923fab6e@Spark X-Microsoft-Original-Message-ID: X-TMN: [WMiLcTuvPa2dEUzQ0j6iCJzeX5nILV5l] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 1eace4ee-8c85-48c9-f37a-08d77d4155e0 X-MS-TrafficTypeDiagnostic: SG2APC01HT237: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9Zo9jlzcTvc4nqR5Urj2VI8zBgtXFomiZYdL76BB1JHdX8PmLoWpY16d8XeL6DHELZMgYLFQe0YEzeoNmLb9FGW6t+e+ZU7xoEmJ7m7qeBRs6I/2Yj0I0tch4ghmi+28dMFZmIm5cfwF+iOHrIE5a5PRUvYt2fAJElkaI/e40F1Z9g2T7HFtSGIm7kDwDAkV X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1eace4ee-8c85-48c9-f37a-08d77d4155e0 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2019 07:19:47.0122 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT237 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:173134 Archived-At: --5def470e_580bd78f_422 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I reported the bug=C2=A0=2334614. I meet the bug(=2334614 like) everyday. One common scene: I push a commit= with magit. And then open a file with C-xC-f, a message (=E2=80=9Cgit fi= nished.=E2=80=9D) comes and replace the find-file prompt. I need to press= C-g and C-xC-f again. This is not a big problem. But minibuffer is a basic UI of emacs. If it a= lways has these bugs, users may think that minibuffer is not a good desig= n. =E5=9C=A8 2019=E5=B9=B412=E6=9C=8810=E6=97=A5 +0800 AM11:37=EF=BC=8CEli Z= aretskii =EF=BC=8C=E5=86=99=E9=81=93=EF=BC=9A > > =46rom: Juri Linkov > > Cc: 38457=40debbugs.gnu.org, stephen.berman=40gmx.net > > Date: Tue, 10 Dec 2019 01:45:18 +0200 > > > > > And the original bug reports definitely were about y-or-n-p. > > > > bug=2334614 was not about y-or-n-p. It was about any command that use= s > > the minibuffer. > > I was talking about the 3 bug reports mentioned in the change's log. > > > > I don't see how this is a =22hack=22 when it uses the same techniqu= e as > > > your changes in 'message': checking a variable that is bound by oth= er > > > functions. The advantage of my proposal is that it makes the new > > > functionality opt-in, so that any commands which need this could ha= ve > > > it by simply binding a variable, and would otherwise maintain its o= ld > > > 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=2334614, bug=2319064, bug=2317272, bug=234= 46. > > Sorry, I don't understand the proposal. How will this variable help > if we leave the current code in 'message' as it is=3F And what do you > mean by =22enabling=22 message-in-echo-area=3F > > > > Type M-x, then press =465 =3D> 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 fe= ature > > 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=3F > > 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=3F 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. > > > --5def470e_580bd78f_422 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I reported the bug #34614.

=
I meet the bug(#34614 like) everyday. One common s= cene: I push a commit with magit. And then open a file with C-xC-f, a messa= ge (=E2=80=9Cgit finished.=E2=80=9D) comes and replace the find-file prompt= . I need to press C-g and C-xC-f again.

This is not= a big problem. But minibuffer is a basic UI of emacs. If it always has the= se bugs, users may think that minibuffer is not a good design.

=E5=9C=A8 2019=E5=B9=B412=E6=9C=8810=E6= =97=A5 +0800 AM11:37=EF=BC=8CEli Zaretskii <eliz@gnu.org>=EF=BC= =8C=E5=86=99=E9=81=93=EF=BC=9A
From: Juri Linkov <= juri@linkov.net>
Cc: 38457@debbugs.gnu.org, stephen.berman@gmx.net
Date: Tue, 10 Dec 2019 01:45:18 +0200

And the original bug r= eports 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 i= s 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 F= 5 =3D> 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<= br> 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.



--5def470e_580bd78f_422--