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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: juri@linkov.net,  38457@debbugs.gnu.org
> Date: Tue, 10 Dec 2019 12:08:14 -0500
> 
> [ I presume that additionally from inserting the minibuffer's contents
>   we'd add some delimiters to clearly separate the message from the
>   minibuffer's contents.  ]

Something like minibuffer-message's "[..]", perhaps?

> I guess there could be some visible artifacts of this subterfuge in the
> case where the minibuffer's content is currently affected by overlays
> (since we presumably wouldn't copy those to the echo-area), but I'm not
> sure this would be a real problem.

We could copy the overlays, if that's important.

> Another issue could be when the minibuffer is large, in which case we'll
> want to try and preserve the window-start but also we'll want to make
> sure the new message is visible.

You mean, if resize-mini-windows is nil?  Otherwise, I see no problem.

If resize-mini-windows is nil, the result will be the same as with the
current code, which calls minibuffer-message: the message is partially
or completely invisible.

> BTW, we should probably think about replacing `message` with something
> that lets the caller give more information about the intended behavior
> (e.g. to also solve the issue of several successive calls to message
> resulting in the user only seeing the last message).  Of course, this
> would be for Emacs-28.

Right.