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.
>
>
>