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

[Stefan Monnier]

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

My gut feeling is that it's not 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?

In any case where the window-start isn't point-min.
That can be due to resize-mini-windows being nil or any other reason.

> Otherwise, I see no problem.

I'm not terribly worried about it either.
I just mentioned it as a problem I could imagine coming up.

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

With the current code (i.e. with minibuffer-message), if
resize-mini-windows is nil and the minibuffer is large enough to matter,
the message is still (partially) visible as long as the currently
displayed part of the minibuffer includes EOB, which is the usual case.

If we simply copy the minibuffer's content to the echo area without
preserving window-start, it will be more disruptive and will make it more
likely that the message isn't visible.


        Stefan