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: Fri, 13 Dec 2019 10:46:46 +0200 Message-ID: <83eex88vex.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> <83h828b0lz.fsf@gnu.org> <83r21aak51.fsf@gnu.org> <87eexabg41.fsf@mail.linkov.net> <83blse9kbj.fsf@gnu.org> <87zhfxjf9w.fsf@mail.linkov.net> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="92583"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38457@debbugs.gnu.org, monnier@iro.umontreal.ca To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 13 09:47:12 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 1ifgbQ-000Nsw-7S for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2019 09:47:12 +0100 Original-Received: from localhost ([::1]:42620 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifgbO-0007nt-N0 for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2019 03:47:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40211) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifgbH-0007nR-8T for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2019 03:47:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ifgbF-0004Ko-Uw for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2019 03:47:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55249) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ifgbF-0004KQ-Qj for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2019 03:47:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ifgbF-0004Pa-Ns for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2019 03:47: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: Fri, 13 Dec 2019 08:47: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.157622681916949 (code B ref 38457); Fri, 13 Dec 2019 08:47:01 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 13 Dec 2019 08:46:59 +0000 Original-Received: from localhost ([127.0.0.1]:32989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ifgbD-0004PJ-CP for submit@debbugs.gnu.org; Fri, 13 Dec 2019 03:46:59 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ifgbA-0004P6-Qa for 38457@debbugs.gnu.org; Fri, 13 Dec 2019 03:46:57 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51760) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ifgb5-00040e-7M; Fri, 13 Dec 2019 03:46:51 -0500 Original-Received: from [176.228.60.248] (port=2670 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ifgb4-0004fy-Ic; Fri, 13 Dec 2019 03:46:51 -0500 In-reply-to: <87zhfxjf9w.fsf@mail.linkov.net> (message from Juri Linkov on Fri, 13 Dec 2019 01:07:39 +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:173253 Archived-At: > From: Juri Linkov > Cc: monnier@iro.umontreal.ca, 38457@debbugs.gnu.org > Date: Fri, 13 Dec 2019 01:07:39 +0200 > > > But 'message' always behaved this way, so using a timeout is change in > > behavior, whereas my proposal leaves the behavior unchanged, and just > > makes the prompt still visible, so it avoids confusing the user. User > > confusion was the main issue that triggered the series of changes we > > are discussing, and it will be resolved by my proposal. > > But 'minibuffer-message' never behaved this way because it's very annoying > when messages remain indefinitely in the minibuffer, and a key is needed > to be pressed to flush mostly useless messages away. > > Messages in the echo-area and messages in the minibuffer are different > things for user interaction. That is exactly my point: these two APIs are very different in the behavior they provide and support. It follows that calling 'minibuffer-message' from 'message' under some circumstances is a radical change in behavior. Such radical changes are fine when we introduce radical new UI features, but the changes we discuss here were made to fix bugs. I'm saying we can fix those bugs without introducing radical new features, which AFAIU are not yet finished, and will probably require many more changes to get them right. We should limit ourselves to fixing the most annoying bugs/misfeatures, and leave the more radical changes for a future major release after Emacs 27. > OTOH, such messages as "Compilation finished" would significantly impact > editing of the minibuffer's content in a negative way when displayed > permanently. When the user is using the minibuffer, the message is very unlikely to stay there indefinitely, since user interaction implies user input, which will remove the message. OTOH, leaving such messages until the next input event will let the user determine when will the message be removed, whereas using a timeout takes that control from the user. What if the message is important, but the user takes a long time to read it, or is distracted by something? > >> If someone wants the message to hang out indefinitely in the minibuffer, > >> this is possible, minibuffer-message-timeout is configurable: > > > > That is a user option, so we cannot change it globally. We could bind > > it temporarily, but how can we know which value to use in each and > > every use case, on the level where you call minibuffer-message from > > inside 'message'? > > I meant that it should be possible to customize the user option. And I was talking about the default operation. The default operation should be reasonable. > > No, my suggestion is not to remove the message automatically at all, > > i.e. leave this aspect of 'message's behavior unchanged. The message > > text will be removed when either the user types something, or when > > some Lisp calls 'message' again to clear the message text. > > It should take into account a user option that specifies the timeout > after which the message should be removed using a timer. > > If you want to leave the message indefinitely by default that's fine, > but the users should have an option not to suffer from the > default behavior that you propose. We already have that default behavior. We had it for eons. I just propose not to change it yet, because the alternative means a radical change in the UI and many changes in low-level infrastructure whose full extent we don't know yet. The way you've decided to solve these problems practically requires us to continue making these radical changes, and that will delay the Emacs 27 release for many moons. And the timing of removal of the message is just one aspect. There are others: the logging in *Messages*, the debug-on-message feature, and I'm sure we will discover more of them. The only "easy" way of solving these is to make 'minibuffer-message' do that stuff as well, which means incompatible changes in 'minibuffer-message', and is likely to raise more issues, which will delay Emacs 27 even more. All that is the consequence of the basic fact that we both agree on: 'message' and 'minibuffer-message' are two very different beasts, so making one call the other has got to cause complications. If we want to release Emacs 27.1 soon (and we should), we cannot continue on this path, we must find a reasonable way of delaying the more radical parts of these changes to Emacs 28.