From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change Date: Fri, 20 Dec 2019 00:16:46 +0200 Organization: LINKOV.NET Message-ID: <87fthgdkq9.fsf@mail.linkov.net> References: <8736e3vve8.fsf@gmx.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> <83y2v81g5s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="166048"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: 38457@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 19 23:21:18 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 1ii4AW-000h1B-EO for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Dec 2019 23:21:16 +0100 Original-Received: from localhost ([::1]:48332 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ii4AV-0007B8-3u for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Dec 2019 17:21:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47697) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ii4AM-00078o-2X for bug-gnu-emacs@gnu.org; Thu, 19 Dec 2019 17:21:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ii4AK-0007Xi-EL for bug-gnu-emacs@gnu.org; Thu, 19 Dec 2019 17:21:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39684) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ii4AI-0007UF-EQ for bug-gnu-emacs@gnu.org; Thu, 19 Dec 2019 17:21:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ii4AI-0005lG-A4 for bug-gnu-emacs@gnu.org; Thu, 19 Dec 2019 17:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Dec 2019 22:21: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.157679405522101 (code B ref 38457); Thu, 19 Dec 2019 22:21:02 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 19 Dec 2019 22:20:55 +0000 Original-Received: from localhost ([127.0.0.1]:45656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ii4AA-0005kP-M3 for submit@debbugs.gnu.org; Thu, 19 Dec 2019 17:20:55 -0500 Original-Received: from azure.elm.relay.mailchannels.net ([23.83.212.7]:35328) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ii4A8-0005kC-1y for 38457@debbugs.gnu.org; Thu, 19 Dec 2019 17:20:52 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id CA79C3C1083; Thu, 19 Dec 2019 22:20:50 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a58.g.dreamhost.com (100-96-14-23.trex.outbound.svc.cluster.local [100.96.14.23]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 56AAB3C16BF; Thu, 19 Dec 2019 22:20:50 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a58.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 19 Dec 2019 22:20:50 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Thread-Cold: 0f434c0567222eed_1576794050579_2785132071 X-MC-Loop-Signature: 1576794050579:3290423846 X-MC-Ingress-Time: 1576794050579 Original-Received: from pdx1-sub0-mail-a58.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTP id 1077F8060C; Thu, 19 Dec 2019 14:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=bktbXjCzAl8YnZBXtJ4YdgYEGqA=; b= uDH6BvZw1HLsFNm67B14n8IvstTFDynhtGCzbGyUsb58NMFJbUPFDCe4maQ5Oii3 Rs0yqQn+L3jGDYE8xzubK0u0hBNsklAPYs8j6Fz15nF3LDZVyPWfZ3qpDDMpHXjf gZqiHir6lj7z5X74BR0A/k4qW1nGIiUD08i0nujO4DE= Original-Received: from mail.jurta.org (m91-129-107-186.cust.tele2.ee [91.129.107.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTPSA id 65AE380617; Thu, 19 Dec 2019 14:20:42 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a58 In-Reply-To: <83y2v81g5s.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 19 Dec 2019 17:36:15 +0200") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrvdduuddgudehlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehmtderredtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledruddtjedrudekieenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrddutdejrddukeeipdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepvghlihiisehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptd 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:173558 Archived-At: --=-=-= Content-Type: text/plain > 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. Implemented in a new patch. >> 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. Actually, supporting an option after-input is not straightforward, because when clear-minibuffer-message is called, there is no distinction whether it was called by new input arrived, or by a function calling 'message' with an empty argument. But really an option after-input is not necessary, this rules out variants 1 and 4 anyway. So this patch implements only the option clear-timeout with the 2nd variant by default. Also made changes for all your previous comments: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=set-minibuffer-message-2.patch diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 76d8ca4475..502375ee1e 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -746,6 +746,76 @@ minibuffer-message (sit-for (or minibuffer-message-timeout 1000000))) (delete-overlay ol))))) +(defcustom minibuffer-message-clear-timeout 2 + "How long to display an echo-area message when the minibuffer is active. +If the value is a number, it should be specified in seconds. +If the value is not a number, such messages never time out, +and the text is displayed until the next input event arrives." + :type '(choice (const :tag "Never time out" nil) + (integer :tag "Wait for the number of seconds" 2)) + :version "27.1") + +(defvar minibuffer-message-timer nil) +(defvar minibuffer-message-overlay nil) + +(defun set-minibuffer-message (message) + "Temporarily display MESSAGE at the end of the minibuffer. +The text is displayed for `minibuffer-message-clear-timeout' seconds +(if the value is a number), or until the next input event arrives, +whichever comes first." + (when (and (not noninteractive) + (window-live-p (active-minibuffer-window))) + (with-current-buffer (window-buffer (active-minibuffer-window)) + (setq message (if (string-match-p "\\` *\\[.+\\]\\'" message) + ;; Make sure we can put-text-property. + (copy-sequence message) + (concat " [" message "]"))) + (unless (or (null minibuffer-message-properties) + ;; Don't overwrite the face properties the caller has set + (text-properties-at 0 message)) + (setq message (apply #'propertize message minibuffer-message-properties))) + + (when (timerp minibuffer-message-timer) + (cancel-timer minibuffer-message-timer) + (setq minibuffer-message-timer nil)) + (when (overlayp minibuffer-message-overlay) + (delete-overlay minibuffer-message-overlay) + (setq minibuffer-message-overlay nil)) + + (setq minibuffer-message-overlay + (make-overlay (point-max) (point-max) nil t t)) + (unless (zerop (length message)) + ;; The current C cursor code doesn't know to use the overlay's + ;; marker's stickiness to figure out whether to place the cursor + ;; before or after the string, so let's spoon-feed it the pos. + (put-text-property 0 1 'cursor t message)) + (overlay-put minibuffer-message-overlay 'after-string message) + + (when (numberp minibuffer-message-clear-timeout) + (setq minibuffer-message-timer + (run-with-timer minibuffer-message-clear-timeout nil + (lambda () + (when (overlayp minibuffer-message-overlay) + (delete-overlay minibuffer-message-overlay) + (setq minibuffer-message-overlay nil) + (setq minibuffer-message-timer nil)))))) + + t))) + +(setq set-message-function 'set-minibuffer-message) + +(defun clear-minibuffer-message () + "Clear minibuffer message." + (when (not noninteractive) + (when (timerp minibuffer-message-timer) + (cancel-timer minibuffer-message-timer) + (setq minibuffer-message-timer nil)) + (when (overlayp minibuffer-message-overlay) + (delete-overlay minibuffer-message-overlay) + (setq minibuffer-message-overlay nil)))) + +(setq clear-message-function 'clear-minibuffer-message) + (defun minibuffer-completion-contents () "Return the user input in a minibuffer before point as a string. In Emacs 22, that was what completion commands operated on. diff --git a/src/keyboard.c b/src/keyboard.c index 5135fd0bc8..5b1b6f2c95 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -2990,6 +2990,8 @@ read_char (int commandflag, Lisp_Object map, safe_run_hooks (Qecho_area_clear_hook); clear_message (1, 0); } + else if (FUNCTIONP (Vclear_message_function)) + message1 (0); } reread_for_input_method: diff --git a/src/xdisp.c b/src/xdisp.c index 08c6927052..3d232d8e92 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -11706,13 +11706,32 @@ truncate_message_1 (ptrdiff_t nchars, Lisp_Object a2) static void set_message (Lisp_Object string) { + Lisp_Object message = Qnil; + eassert (STRINGP (string)); - message_enable_multibyte = STRING_MULTIBYTE (string); + if (FUNCTIONP (Vset_message_function)) + { + ptrdiff_t count = SPECPDL_INDEX (); + specbind (Qinhibit_quit, Qt); + message = safe_call1 (Vset_message_function, string); + unbind_to (count, Qnil); - with_echo_area_buffer (0, -1, set_message_1, 0, string); - message_buf_print = false; - help_echo_showing_p = false; + if (STRINGP (message)) + { + string = message; + message = Qnil; + } + } + + if (NILP (message)) + { + message_enable_multibyte = STRING_MULTIBYTE (string); + + with_echo_area_buffer (0, -1, set_message_1, 0, string); + message_buf_print = false; + help_echo_showing_p = false; + } if (STRINGP (Vdebug_on_message) && STRINGP (string) @@ -11768,6 +11787,14 @@ clear_message (bool current_p, bool last_displayed_p) { echo_area_buffer[0] = Qnil; message_cleared_p = true; + + if (FUNCTIONP (Vclear_message_function)) + { + ptrdiff_t count = SPECPDL_INDEX (); + specbind (Qinhibit_quit, Qt); + safe_call (1, Vclear_message_function); + unbind_to (count, Qnil); + } } if (last_displayed_p) @@ -34940,6 +34967,14 @@ syms_of_xdisp (void) doc: /* If non-nil, debug if a message matching this regexp is displayed. */); Vdebug_on_message = Qnil; + DEFVAR_LISP ("set-message-function", Vset_message_function, + doc: /* If non-nil, function to set message. */); + Vset_message_function = Qnil; + + DEFVAR_LISP ("clear-message-function", Vclear_message_function, + doc: /* If non-nil, function to clear message. */); + Vclear_message_function = Qnil; + DEFVAR_LISP ("redisplay--all-windows-cause", Vredisplay__all_windows_cause, doc: /* */); Vredisplay__all_windows_cause = Fmake_hash_table (0, NULL); --=-=-=--