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, 16 Dec 2019 18:09:38 +0200 Message-ID: <8336dk5k1p.fsf@gnu.org> References: <8736e3vve8.fsf@gmx.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> <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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="33689"; 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 Mon Dec 16 17:11:11 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 1igsxj-0008ZI-E3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Dec 2019 17:11:11 +0100 Original-Received: from localhost ([::1]:56262 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igsxi-0000RG-18 for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Dec 2019 11:11:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48522) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igsxc-0000R6-QN for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2019 11:11:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1igsxb-0002JA-K7 for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2019 11:11:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34332) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1igsxb-0002Iy-Gi for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2019 11:11:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1igsxa-0003uU-70 for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2019 11:11: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, 16 Dec 2019 16:11: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.157651260314956 (code B ref 38457); Mon, 16 Dec 2019 16:11:02 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 16 Dec 2019 16:10:03 +0000 Original-Received: from localhost ([127.0.0.1]:40305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1igswc-0003tA-Gn for submit@debbugs.gnu.org; Mon, 16 Dec 2019 11:10:02 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39213) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1igswa-0003sZ-Fu for 38457@debbugs.gnu.org; Mon, 16 Dec 2019 11:10:01 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33186) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1igswV-0001OS-2C; Mon, 16 Dec 2019 11:09:55 -0500 Original-Received: from [176.228.60.248] (port=3675 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1igswU-000335-E0; Mon, 16 Dec 2019 11:09:54 -0500 In-reply-to: <878snd2liu.fsf@mail.linkov.net> (message from Juri Linkov on Mon, 16 Dec 2019 01:59:45 +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:173442 Archived-At: > From: Juri Linkov > Cc: 38457@debbugs.gnu.org > Date: Mon, 16 Dec 2019 01:59:45 +0200 > > > IOW, introduce a new option, which will affect the new function we > > were talking about, a near-clone of minibuffer-message (and will not > > affect minibuffer-message itself). When that new option's value is > > not a number, the near-clone of minibuffer-message should not call > > sit-for at all; and when that value is a number, use a timer to remove > > the message after that many seconds if no input arrives before that. > > > > In any case, I thought we agreed not to call minibuffer-message from > > 'message', but define a new function, similar but not identical to > > minibuffer-message (what I call a "near-clone"). And > > minibuffer-message-timeout should not affect that new function, it > > should be a separate option. > > I agree that a new function needs to be created, and agree > not to call minibuffer-message from 'message'. OK. > >> 8693611136 > >> aa89c84e00 > >> 54c792ece6 > >> > >> Please revert them if you want. > > > > Thanks. Let's revisit these after the implementation of the > > minibuffer-message's clone is finalized, so that we could know which > > ones of these are still needed and which aren't. > > Since a new near-clone of minibuffer-message is needed, and > we agreed to not call minibuffer-message from 'message', > I reverted all previous changes. > > Now a new feature could be implemented from scratch. > > I created a new ELPA package attached below that > implements this feature. So everyone who like it > can use it even after release. Also this package > could be used for experimentation to find the best way > to use it, that later could be moved to core in Emacs 28. > > I think now we have no moral right to delay the Emacs 27 pretest > anymore. Thanks. 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. 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. Do you see any danger with the above? If not, can I persuade you do install such a change? > (defun minimess-message (orig-fun format-string &rest args) > (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? Thanks.