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

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