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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 10 Dec 2019 05:36:24 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 38457@debbugs.gnu.org, stephen.berman@gmx.net
> 
> > > 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?

Actually, the more I think about this the less I like the idea of
calling minibuffer-message instead of 'message' under some
circumstances, any circumstances.  minibuffer-message is meant for
very different use case: temporarily displaying a message for a short
time.  The messages it displays are usually ephemeral and dispensable;
if the user misses such a message, no big deal.

By contrast, 'message' is used for similar use cases, but also for
radically different ones, including those where several related
messages are displayed in quick succession (a notable example is
"Foo..." followed by "Foo...done"), or where a message is left in the
echo area indefinitely if no input event arrives.  Crucially, Lisp
programs do not tell 'message' which use case is required; instead,
the following calls to 'message' or other events produce the required
effects.  To produce the same effect with minibuffer-message will
require too many changes all over the place.

So I think it is simply wrong to call minibuffer-message instead of
'message'.  There are too many different behavior aspects.  Several
examples were already given, including debug-on-message.  One other
aspect that I just bumped into is recording messages in the *Messages*
buffer: minibuffer-message never did that, until a recent (and
undocumented) change, also related to attempts to fix messages
overwriting y-or-n-p prompts, so now we have one more incompatible
change in minibuffer-message's behavior waiting to bite us down the
road.

Therefore, I suggest to take a step back and discuss a better solution
for these problems.

The original problem was, AFAIU, that various minibuffer prompts
become obscured by echo-area display of messages.  So one possible
solution is to modify the subroutines of 'message', e.g.,
set_message_1, to detect the conditions of the minibuffer being
active, and insert the contents of the minibuffer into the echo-area
buffer before the message text.  Does anyone see problems with this?