bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38457: 27.0.50; dabbrev-expand regression due to message change


From: Juri Linkov
Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change
Date: Tue, 10 Dec 2019 01:45:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)

>> No, it was not only about y-or-n-p, but about any command that uses the 
>> minibuffer.
>
> As it turns out, not any command, because "M-x" and "C-x C-f" also use
> the minibuffer.
>
> And the original bug reports definitely were about y-or-n-p.

bug#34614 was not about y-or-n-p.  It was about any command that uses
the minibuffer.

> I don't see how this is a "hack" when it uses the same technique as
> your changes in 'message': checking a variable that is bound by other
> functions.  The advantage of my proposal is that it makes the new
> functionality opt-in, so that any commands which need this could have
> it by simply binding a variable, and would otherwise maintain its old
> behavior, which was there for eons.

Such variable already exists.  It's called message-in-echo-area.
You can enable it in the release branch if you want.
But then please reopen bug#34614, bug#19064, bug#17272, bug#446.

> Here's one more problem with the new behavior of 'message':
>
>   emacs -Q
>
>   Evaluate:
>
>   (defun my-mesage ()
>     (interactive)
>     (message "my most important message"))
>   (global-set-key [f5] 'my-mesage)
>   (setq debug-on-message "important")
>
>   Press F5, observe the debugger pop up, as expected.
>   Type C-] to exit the debugger.
>   Type M-x, then press F5 => the debugger doesn't start, although the
>     message appears that should have triggered the debugger.

This is exactly the purpose of the pretest - you are testing a new feature
or a bug fix, then discover that some feature doesn't work, report it,
and the following patch implements the missing feature.

Looking at the recent log, there are many fixes in core functions
with potentially destabilizing changes still committed every day.
How fixes in minibuffer-message are different from other
more risky fixes in other core functions?

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 8af8aca30e..125a711b54 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -749,7 +749,11 @@ minibuffer-message
               (put-text-property 0 1 'cursor t message))
             (overlay-put ol 'after-string message)
             (sit-for (or minibuffer-message-timeout 1000000)))
-        (delete-overlay ol)))))
+        (delete-overlay ol)))
+    (when (and (stringp debug-on-message)
+               (stringp message)
+               (string-match-p debug-on-message message))
+      (debug message))))
 
 (defun minibuffer-completion-contents ()
   "Return the user input in a minibuffer before point as a string.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]