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, 17 Dec 2019 18:11:05 +0200 Message-ID: <83immf3pba.fsf@gnu.org> References: <8736e3vve8.fsf@gmx.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> <87d0cubfxx.fsf@mail.linkov.net> <83a77y9k35.fsf@gnu.org> <87eex9jf14.fsf@mail.linkov.net> <83d0cs8uw8.fsf@gnu.org> <87a77uh5a5.fsf@mail.linkov.net> <83r21561qd.fsf@gnu.org> <878snd2liu.fsf@mail.linkov.net> <8336dk5k1p.fsf@gnu.org> <87a77rgajf.fsf@mail.linkov.net> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="135904"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38457@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 17 17:12: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 1ihFSN-000ZDU-2g for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Dec 2019 17:12:19 +0100 Original-Received: from localhost ([::1]:42618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihFSL-0000VT-Oj for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Dec 2019 11:12:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43098) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihFS7-0000RK-UM for bug-gnu-emacs@gnu.org; Tue, 17 Dec 2019 11:12:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihFS6-0006kA-FZ for bug-gnu-emacs@gnu.org; Tue, 17 Dec 2019 11:12:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36286) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ihFS6-0006j0-Bi for bug-gnu-emacs@gnu.org; Tue, 17 Dec 2019 11:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ihFS6-00072G-6Y for bug-gnu-emacs@gnu.org; Tue, 17 Dec 2019 11:12: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, 17 Dec 2019 16:12: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.157659908727002 (code B ref 38457); Tue, 17 Dec 2019 16:12:02 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 17 Dec 2019 16:11:27 +0000 Original-Received: from localhost ([127.0.0.1]:42259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ihFRW-00071R-KK for submit@debbugs.gnu.org; Tue, 17 Dec 2019 11:11:26 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33650) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ihFRV-00071C-16 for 38457@debbugs.gnu.org; Tue, 17 Dec 2019 11:11:25 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ihFRP-00046t-Gx; Tue, 17 Dec 2019 11:11:19 -0500 Original-Received: from [176.228.60.248] (port=3785 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ihFRO-0003IC-D7; Tue, 17 Dec 2019 11:11:19 -0500 In-reply-to: <87a77rgajf.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 17 Dec 2019 00:29:32 +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:173487 Archived-At: > From: Juri Linkov > Cc: 38457@debbugs.gnu.org > Date: Tue, 17 Dec 2019 00:29:32 +0200 > > > However, I hoped we could have at least part of what you did in Emacs > > 27, and not lose all of it. We could install a function like > > 'minimess-minibuffer-message', and make one of the subroutines of > > 'message' call it under the right conditions. > > The most low-level functions where it could be called from > are 'set_message' and 'clear_message'. I had in mind set_message_1 rather than set_message, but the difference is not critical for this discussion. > > Then the message which > > 'minimess-minibuffer-message' displays could be removed by a timer if > > the new timeout defcustom is a number, and if that defcustom is not a > > number (which will be the default), the message stays and sit-for is > > not called. > > This is almost how 'minimess-minibuffer-message' was implemented, > with one difference: defcustom is a number by default. > Why shouldn't it be a number by default? By making the default not a number, we keep the previous behavior of 'message' in this aspect, thus minimizing potential unintended consequences. At the same time, we gain another aspect: we avoid hiding the minibuffer prompt. So this will be a partial improvement wrt the current behavior, with an option for users who would like that to customize the value to a number, and thus get the message removed automatically after some delay. > How the user would be able to remove an old message when the > function doesn't call sit-for? Like they do today: type something. And in some situations, not even that, if the Lisp program which displayed the message will shortly follow up with clearing the echo area (that's what happens with dabbrev, for example). > > Do you see any danger with the above? If not, can I persuade you do > > install such a change? > > I'm not sure if now is the right time to implement this feature. > But if implementation would be straightforward and if you see no problems > then why not. The implementation looks straightforward to me, since you already implemented almost all of it in that ELPA package. What's left is minor details. > >> (if (and > >> ;; When `inhibit-message' is non-nil, the intention was to just > >> ;; log the message to the *Messages* buffer using `message'. > >> (null inhibit-message) > >> (window-live-p (active-minibuffer-window)) > >> (window-live-p (old-selected-window)) > >> (bufferp (window-buffer (old-selected-window))) > >> (minibufferp (window-buffer (old-selected-window)))) > > > > Btw, can you explain why every part of this condition is needed? IOW, > > why isn't just the below enough? > > > > (window-live-p (active-minibuffer-window)) > > > > (I do understand the reason for the test of inhibit-message). > > > > Maybe the other conditions need a comment to explain them? > > Unfortunately, I forgot why they were added, i.e. during testing > I added them one by one when noticed that some cases don't work. > Now I'll try to reproduce these cases by removing conditions > and checking which part doesn't work. Thank you.