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

[Eli Zaretskii]

On December 8, 2019 5:28:31 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Juri Linkov <juri@linkov.net>
> > Cc: stephen.berman@gmx.net,  38457@debbugs.gnu.org
> > Date: Sun, 08 Dec 2019 01:05:03 +0200
> > 
> > > I just suggested another possible solution: bind
> > > 'minibuffer-message-timeout' to zero when calling
> 'minibuffer-message'
> > > from 'message'.  Would that work, or will it have some unwanted
> side
> > > effects?
> > 
> > Kévin posted a patch that binds 'minibuffer-message-timeout' to
> zero, but
> > it makes each message disappear before the user has a chance to read
> it.
> 
> But that's how 'message' behaved as well, didn't it?

In case the answer is NO, here's an alternative proposal.

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.

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?