bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change
Date: Thu, 12 Dec 2019 07:36:32 +0200

> From: Juri Linkov <juri@linkov.net>
> Cc: monnier@iro.umontreal.ca,  38457@debbugs.gnu.org
> Date: Thu, 12 Dec 2019 01:24:30 +0200
> 
> 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.

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

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]