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

[HaiJun Zhang]

I reported the bug #34614.

I meet the bug(#34614 like) everyday. One common scene: I push a commit with magit. And then open a file with C-xC-f, a message (“git finished.”) comes and replace the find-file prompt. I need to press C-g and C-xC-f again.

This is not a big problem. But minibuffer is a basic UI of emacs. If it always has these bugs, users may think that minibuffer is not a good design.

在 2019年12月10日 +0800 AM11:37，Eli Zaretskii <eliz@gnu.org>，写道：

From: Juri Linkov <juri@linkov.net>
Cc: 38457@debbugs.gnu.org, stephen.berman@gmx.net
Date: Tue, 10 Dec 2019 01:45:18 +0200

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 was talking about the 3 bug reports mentioned in the change's log.

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.

Sorry, I don't understand the proposal. How will this variable help
if we leave the current code in 'message' as it is? And what do you
mean by "enabling" message-in-echo-area?

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.

I expect to see a lot of such problems, and consequently a lot of
patches. More importantly, I expect quite a few of those to slip into
the release. That's because minibuffer-message's behavior is very
different from that of 'message', and these differences will bite us
every turn for a long time.

This is not the right way of fixing the problems with overwriting the
prompts by messages. It will certainly prolong the pretest too much,
and most probably leave some problems undiscovered and unsolved.

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?

They are much more risky because they are in an infrastructure used
all over the place, and also because the method selected for
displaying such messages by minibuffer-message changes the behavior in
very significant ways, so it will certainly cause many unintended
consequences.

The patch below also changes the behavior of minibuffer-message wrt
debug-on-message, doesn't it? If so, we cannot install it as shown.

We must find a better solution for the original problems, or decide to
postpone the solution till after Emacs 27. Please help me in this
matter.

Thanks.