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

[Juri Linkov]

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

Yes, the answer is NO.

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

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