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 18:34:48 +0200 Message-ID: <83h828b0lz.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> <83tv68c0nb.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="81272"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38457@debbugs.gnu.org To: juri@linkov.net, Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 10 17:36:53 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 1ieiVJ-000L0Q-GB for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 17:36:53 +0100 Original-Received: from localhost ([::1]:58854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieiVI-0004jS-75 for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 11:36:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56959) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieiUW-0003gM-Hn for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 11:36:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ieiUU-0001n0-Cu for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 11:36:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50488) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ieiUU-0001mw-9q for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 11:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ieiUU-0008MO-77 for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 11:36: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: Tue, 10 Dec 2019 16:36: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.157599570832065 (code B ref 38457); Tue, 10 Dec 2019 16:36:02 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 10 Dec 2019 16:35:08 +0000 Original-Received: from localhost ([127.0.0.1]:56461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieiTc-0008L5-4F for submit@debbugs.gnu.org; Tue, 10 Dec 2019 11:35:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47699) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieiTa-0008Ka-UK for 38457@debbugs.gnu.org; Tue, 10 Dec 2019 11:35:07 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ieiTV-0001Vz-EA; Tue, 10 Dec 2019 11:35:01 -0500 Original-Received: from [176.228.60.248] (port=1886 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ieiTU-0000Na-Iu; Tue, 10 Dec 2019 11:35:01 -0500 In-reply-to: <83tv68c0nb.fsf@gnu.org> (message from Eli Zaretskii on Tue, 10 Dec 2019 05:36:24 +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:173144 Archived-At: > Date: Tue, 10 Dec 2019 05:36:24 +0200 > From: Eli Zaretskii > Cc: 38457@debbugs.gnu.org, stephen.berman@gmx.net > > > > 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? Actually, the more I think about this the less I like the idea of calling minibuffer-message instead of 'message' under some circumstances, any circumstances. minibuffer-message is meant for very different use case: temporarily displaying a message for a short time. The messages it displays are usually ephemeral and dispensable; if the user misses such a message, no big deal. By contrast, 'message' is used for similar use cases, but also for radically different ones, including those where several related messages are displayed in quick succession (a notable example is "Foo..." followed by "Foo...done"), or where a message is left in the echo area indefinitely if no input event arrives. Crucially, Lisp programs do not tell 'message' which use case is required; instead, the following calls to 'message' or other events produce the required effects. To produce the same effect with minibuffer-message will require too many changes all over the place. So I think it is simply wrong to call minibuffer-message instead of 'message'. There are too many different behavior aspects. Several examples were already given, including debug-on-message. One other aspect that I just bumped into is recording messages in the *Messages* buffer: minibuffer-message never did that, until a recent (and undocumented) change, also related to attempts to fix messages overwriting y-or-n-p prompts, so now we have one more incompatible change in minibuffer-message's behavior waiting to bite us down the road. Therefore, I suggest to take a step back and discuss a better solution for these problems. The original problem was, AFAIU, that various minibuffer prompts become obscured by echo-area display of messages. So one possible solution is to modify the subroutines of 'message', e.g., set_message_1, to detect the conditions of the minibuffer being active, and insert the contents of the minibuffer into the echo-area buffer before the message text. Does anyone see problems with this?