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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: bug-gnu-emacs@gnu.org,  38457@debbugs.gnu.org, stephen.berman@gmx.net
> Date: Sun, 08 Dec 2019 23:50:28 +0200
> 
> > The original problem which the change in 'message' tried to solve, the one
> > reported in bugs #17272 and #19064, was about calling 'message' when
> > y-or-n-p is prompting the user.  So how about if we modify the conditions
> > under which 'message' calls 'minibuffer-message' such that this happens
> > only when y-or-n-p is in progress?  E.g., y-or-n-p could bind some variable
> > that 'message' would check.
> 
> 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.

> > Maybe yes-or-no-p should do the same.
> >
> > This will allow us to fix the original bugs without such wide implications 
> > as we have now.
> >
> > And while at that, I don't think we need the new function 
> > message-on-echo-area; the additional logic could be added to 'message's 
> > original code.
> >
> > WDYT?
> 
> Inventing hacks and workarounds is too risky and error-prone
> than installing the proper and safest solution.

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.

This issue is basically the only one that's left before we can cut the
release branch.  Please help me resolve this issue so that we could
start the pretest of Emacs 27.

Thanks.