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: Thu, 19 Dec 2019 17:36:15 +0200 Message-ID: <83y2v81g5s.fsf@gnu.org> References: <8736e3vve8.fsf@gmx.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> <83immf3pba.fsf@gnu.org> <87y2vawly3.fsf@mail.linkov.net> <83tv5x38kq.fsf@gnu.org> <87d0clxjaq.fsf@mail.linkov.net> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="55697"; 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 Thu Dec 19 16:37: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 1ihxrT-000EN3-Ff for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Dec 2019 16:37:11 +0100 Original-Received: from localhost ([::1]:43702 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihxrS-0007Z7-A2 for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Dec 2019 10:37:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56656) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihxrM-0007Z1-K9 for bug-gnu-emacs@gnu.org; Thu, 19 Dec 2019 10:37:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihxrL-00064Z-9j for bug-gnu-emacs@gnu.org; Thu, 19 Dec 2019 10:37:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39437) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ihxrK-00062q-Em for bug-gnu-emacs@gnu.org; Thu, 19 Dec 2019 10:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ihxrK-0004A7-6x for bug-gnu-emacs@gnu.org; Thu, 19 Dec 2019 10:37: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: Thu, 19 Dec 2019 15:37: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.157676979115916 (code B ref 38457); Thu, 19 Dec 2019 15:37:02 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 19 Dec 2019 15:36:31 +0000 Original-Received: from localhost ([127.0.0.1]:45410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ihxqp-00048c-5D for submit@debbugs.gnu.org; Thu, 19 Dec 2019 10:36:31 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45004) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ihxqn-00048D-79 for 38457@debbugs.gnu.org; Thu, 19 Dec 2019 10:36:29 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ihxqh-0003ql-Ml; Thu, 19 Dec 2019 10:36:23 -0500 Original-Received: from [176.228.60.248] (port=2489 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ihxqh-0002rb-3j; Thu, 19 Dec 2019 10:36:23 -0500 In-reply-to: <87d0clxjaq.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 19 Dec 2019 02:12:09 +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:173547 Archived-At: > From: Juri Linkov > Cc: 38457@debbugs.gnu.org > Date: Thu, 19 Dec 2019 02:12:09 +0200 > > >> 0. emacs -Q > >> 1. M-x ;; activate the minibuffer > >> 2. C-x o ;; switch back to *scratch* > >> 3. Eval in *scratch* buffer: > >> > >> (window-live-p (active-minibuffer-window)) > >> => t > > > > OK, but the minibuffer is still active in this case, and leaving it > > unobscured is still an advantage, right? > > It never occurred to me that someone might want to see the minibuffer > unobscured when the minibuffer is not the current buffer. I think leaving "M-x" (or any other prompt) unobscured in this situation is a nice benefit, and if it simplifies the code, it's even more desirable. > >> +(defun set-minibuffer-message (message) > >> + "Temporarily display MESSAGE at the end of the minibuffer. > >> +The text is displayed for `minibuffer-message-wait' seconds, > >> +or until the next input event arrives, whichever comes first. > > > > This text needs to be updated to refer to minibuffer-message-wait's > > effect on what it does. > > While thinking again about 'minibuffer-message-wait' I realized that > maybe we need two customizable variables: > > 1. minibuffer-message-clear-after-input > 2. minibuffer-message-clear-after-timeout > > because users might prefer customization of these behaviors separately. > Here are all possible combinations (2 is an example of number of seconds, > 0 means no timeout): > > after-input=nil after-timeout=0 - never clear the message > after-input=t after-timeout=2 - clear either on input or after timeout > after-input=t after-timeout=0 - clear only when input is available: > this has an advantage that user has control when > wants to clear message immediately on keypress; > after-input=nil after-timeout=2 - clear only after timeout, not on input: > this has an advantage that user will never miss > a message while typing in the minibuffer, > the message will stay for the specified number > of seconds regardless of input, > so user will have a chance to read it > > Do all these variants make sense? I would never want to use variants 1 and 4, but if someone wants them, I won't object as long as the default for Emacs 27 is as in the 2nd variant. Thanks.