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

[Drew Adams]

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

+1

I couldn't agree more.  In fact, I said
all of that in earlier messages here.

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

I don't think that's a great approach.  It's
not about whether the minibuffer is active.

As a useful first approximation for approaching
these problems, perhaps just assume that the
minibuffer is _always_ active.  There's always
the possibility that some minibuffer interaction
is in progress.

Now, how to deal with some other interaction
that (fairly) wants to jump in and interrupt?

That's the question - whether that's a report
from an async process or a new confirmation
dialog, or whatever.

In general, I think such other interactions
should be the focus of our fixes.  For any
such: should it maybe be modal?  Should it
maybe report elsewhere (e.g. in some popup
buffer)?  Does it need to be logged, and if
so should that maybe be elsewhere than in
`*Messages*'?

Focusing on reports by async operations and
dialogs (e.g. confirmation dialogs) that
either should be modal or should happen
otherwise than by simply reading a key/char,
would be a good start, I think.