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: Mon, 09 Dec 2019 16:00:04 +0200 Message-ID: <83d0cxd2fv.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> <87r21eosfk.fsf@gnus.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="123136"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38457@debbugs.gnu.org, stephen.berman@gmx.net, Richard Stallman , juri@linkov.net To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 09 15:01:40 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 1ieJbY-000Vu5-2O for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Dec 2019 15:01:40 +0100 Original-Received: from localhost ([::1]:40528 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieJbW-0006CS-QM for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Dec 2019 09:01:38 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59542) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieJb5-00068l-7w for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 09:01:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ieJax-0008Bg-Fd for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 09:01:11 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46827) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ieJaw-0008BO-CX for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 09:01:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ieJaw-0002yY-Bt for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 09:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Dec 2019 14:01: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.157590004711383 (code B ref 38457); Mon, 09 Dec 2019 14:01:02 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 9 Dec 2019 14:00:47 +0000 Original-Received: from localhost ([127.0.0.1]:52800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieJag-0002xW-NU for submit@debbugs.gnu.org; Mon, 09 Dec 2019 09:00:47 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50411) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieJae-0002x3-PD for 38457@debbugs.gnu.org; Mon, 09 Dec 2019 09:00:45 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ieJaY-00086q-Vz; Mon, 09 Dec 2019 09:00:39 -0500 Original-Received: from [176.228.60.248] (port=4268 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ieJaG-0003eV-K2; Mon, 09 Dec 2019 09:00:25 -0500 In-reply-to: <87r21eosfk.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 09 Dec 2019 08:43:11 +0100) 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:173106 Archived-At: > From: Lars Ingebrigtsen > Cc: Juri Linkov , 38457@debbugs.gnu.org, > stephen.berman@gmx.net > Date: Mon, 09 Dec 2019 08:43:11 +0100 > > > As it turns out, not any command, because "M-x" and "C-x C-f" also use > > the minibuffer. > > > > And the original bug reports definitely were about y-or-n-p. > > That's true, but I think the way it works now is a huge improvement. > Just about whatever I'm doing now, asynchronous messaging does not > overwrite prompts/M-x actions, and that's really nice. > > The bug reports may have been about y-or-n-p, but it's a general problem > that's been solved in a general way now. Reverting this would be a step > in the wrong direction. I didn't suggest to revert it, I suggested to modify it so that we could selectively enable the feature where it doesn't have adverse side effects. By contrast, what we have now summarily enables the feature for every use of the minibuffer, and we will then have to somehow disable or augment it in every case where it does have adverse side effects. We already have 2 bug reports about it for 2 separate packages, and we cannot leave them unsolved. I'm sure this is just the tip of a very large iceberg. How do you propose we move forward? You think we should install the timer proposed by Juri instead? That would make this change even more invasive than it already is, and will again affect every use of the minibuffer, and then some. And I have no doubt that the delay in removing the message is not the only side effect of the change in how 'message' now works, it's just the first one we noticed. This is a sure way to delay Emacs 27 even further. We are developing Emacs 27 for more than 1.5 years. We need to start its release cycle very soon, and we should start from a stable code base. I have been asking people since July to avoid putting destabilizing changes on master. The change in 'message' destabilized what we had before, and the proposed timer will destabilize it even more. How long do we want the Emacs 27.1 pretest to last? a year? more? We could also revert the change now and reapply it after the emacs-27 branch is cut. That would mean the original use case with y-or-n-p will not be fixed until Emacs 28. Personally, I think it would be a pity to leave that issue unsolved in Emacs 27, but if I cannot get us to agree to any other solution, maybe that's what we should do. More generally, I need everyone's help in making Emacs 27.1 happen soon enough. I cannot do it if people discount my gut feelings about Emacs stability when those gut feelings are strong enough for me to object to changes. It's unfair to expect me to agree to something when every bit of my experience screams that it's wrong. If I cannot get people to bear with me even on rare occasions when I have those gut feelings, I guess I'm unfit for the job, and someone else should take over.