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

[Juri Linkov <juri@linkov.net>]

>> The problem is in usability: it would be very annoying if the message
>> displayed at the end of the minibuffer's contents would not vanish
>> after some time.  minibuffer-message removes the message
>> after 2 sec by default.
>
> But 'message' always behaved this way, so using a timeout is change in
> behavior, whereas my proposal leaves the behavior unchanged, and just
> makes the prompt still visible, so it avoids confusing the user.  User
> confusion was the main issue that triggered the series of changes we
> are discussing, and it will be resolved by my proposal.

But 'minibuffer-message' never behaved this way because it's very annoying
when messages remain indefinitely in the minibuffer, and a key is needed
to be pressed to flush mostly useless messages away.

Messages in the echo-area and messages in the minibuffer are different
things for user interaction.  Most messages are useless, but they don't
get into the way of editing in a buffer when the minibuffer is not active
and useless messages are displayed in the echo-area far away from the
editing area in the buffer.

OTOH, such messages as "Compilation finished" would significantly impact
editing of the minibuffer's content in a negative way when displayed
permanently.

>> If someone wants the message to hang out indefinitely in the minibuffer,
>> this is possible, minibuffer-message-timeout is configurable:
>
> That is a user option, so we cannot change it globally.  We could bind
> it temporarily, but how can we know which value to use in each and
> every use case, on the level where you call minibuffer-message from
> inside 'message'?

I meant that it should be possible to customize the user option.

>> But this means that your proposed implementation still should use timers
>> to remove the echo-area with the appended message after the amount of time
>> specified by minibuffer-message-timeout is passed (when its value is a number).
>
> No, my suggestion is not to remove the message automatically at all,
> i.e. leave this aspect of 'message's behavior unchanged.  The message
> text will be removed when either the user types something, or when
> some Lisp calls 'message' again to clear the message text.

It should take into account a user option that specifies the timeout
after which the message should be removed using a timer.

If you want to leave the message indefinitely by default that's fine,
but the users should have an option not to suffer from the
default behavior that you propose.