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: Juri Linkov
Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change
Date: Fri, 13 Dec 2019 01:12:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)

>> When message-in-echo-area is non-nil, then 'message' has exactly
>> the same behavior as before, as in the previous versions.
>>
>> I propose to use timers in minibuffer-message conditionally
>> only when message-in-echo-area is nil.  Then the behavior
>> of minibuffer-message will be exactly the same as before too
>> when message-in-echo-area is non-nil.
>>
>> If you want to set message-in-echo-area to t in the release branch,
>> that's fine.
>
> That would mean bring back all the problems for which these changes
> were made.  So it would be the worst of all worlds, and thus makes
> very little sense to me.

Then your proposed implementation should be activated when
minibuffer-message-timeout is set to a non-nil value.
Otherwise, when it's a number, it should use the timer.

> And in any case, minibuffer-message already behaves differently: it
> logs the message in *Messages*, something it never did and is not
> documented, and you suggested another change, to make it start the
> debugger per debug-on-message.  These change behavior of any direct
> callers of minibuffer-message in incompatible ways, something I don't
> think we have a good reason to do.

I see no reason not to change minibuffer-message.  But if you think
it should never change, let's create a duplicate function
message-in-minibuffer.





reply via email to

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