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: Tue, 17 Dec 2019 00:29:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)

> However, I hoped we could have at least part of what you did in Emacs
> 27, and not lose all of it.  We could install a function like
> 'minimess-minibuffer-message', and make one of the subroutines of
> 'message' call it under the right conditions.

The most low-level functions where it could be called from
are 'set_message' and 'clear_message'.

> Then the message which
> 'minimess-minibuffer-message' displays could be removed by a timer if
> the new timeout defcustom is a number, and if that defcustom is not a
> number (which will be the default), the message stays and sit-for is
> not called.

This is almost how 'minimess-minibuffer-message' was implemented,
with one difference: defcustom is a number by default.
Why shouldn't it be a number by default?  How the user would be able
to remove an old message when the function doesn't call sit-for?

> Do you see any danger with the above?  If not, can I persuade you do
> install such a change?

I'm not sure if now is the right time to implement this feature.
But if implementation would be straightforward and if you see no problems
then why not.

>> (defun minimess-message (orig-fun format-string &rest args)
>>   (if (and
>>        ;; When `inhibit-message' is non-nil, the intention was to just
>>        ;; log the message to the *Messages* buffer using `message'.
>>        (null inhibit-message)
>>        (window-live-p (active-minibuffer-window))
>>        (window-live-p (old-selected-window))
>>        (bufferp (window-buffer (old-selected-window)))
>>        (minibufferp (window-buffer (old-selected-window))))
>
> Btw, can you explain why every part of this condition is needed?  IOW,
> why isn't just the below enough?
>
>    (window-live-p (active-minibuffer-window))
>
> (I do understand the reason for the test of inhibit-message).
>
> Maybe the other conditions need a comment to explain them?

Unfortunately, I forgot why they were added, i.e. during testing
I added them one by one when noticed that some cases don't work.
Now I'll try to reproduce these cases by removing conditions
and checking which part doesn't work.





reply via email to

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