[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: |
Thu, 19 Dec 2019 02:12:09 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
>> Now I recall why just (window-live-p (active-minibuffer-window))
>> is not enough. Because it returns non-nil even when the
>> current buffer is not the minibuffer, but the minibuffer was
>> activated earlier. Test case:
>>
>> 0. emacs -Q
>> 1. M-x ;; activate the minibuffer
>> 2. C-x o ;; switch back to *scratch*
>> 3. Eval in *scratch* buffer:
>>
>> (window-live-p (active-minibuffer-window))
>> => t
>
> OK, but the minibuffer is still active in this case, and leaving it
> unobscured is still an advantage, right?
It never occurred to me that someone might want to see the minibuffer
unobscured when the minibuffer is not the current buffer.
>> A message overlay should not be added to the *scratch* buffer, so it's
>> important to check if old-selected-window is a minibuffer window
>> (i.e. the current buffer is the minibuffer).
>
> OK, but couldn't we instead do something like
>
> (with-current-buffer (window-buffer (active-minibuffer-window))
> ....
>
> to ensure we add the overlay in the minibuffer, not in *scratch*? Or
> am I missing something?
Maybe. Actually I have no opinion for this case because it never was
a problem when the non-current minibuffer was obscured by messages.
>> Let's iron out the details. A new patch attached works well
>> in all cases I tested (dabbrev, icomplete, etc.) But I'm sure
>> it could be improved further because I might have made wrong
>> assumptions on the C side, or something.
>
> Thanks, I have only a few minor comments:
>
>> +(defun set-minibuffer-message (message)
>> + "Temporarily display MESSAGE at the end of the minibuffer.
>> +The text is displayed for `minibuffer-message-wait' seconds,
>> +or until the next input event arrives, whichever comes first.
>
> This text needs to be updated to refer to minibuffer-message-wait's
> effect on what it does.
While thinking again about 'minibuffer-message-wait' I realized that
maybe we need two customizable variables:
1. minibuffer-message-clear-after-input
2. minibuffer-message-clear-after-timeout
because users might prefer customization of these behaviors separately.
Here are all possible combinations (2 is an example of number of seconds,
0 means no timeout):
after-input=nil after-timeout=0 - never clear the message
after-input=t after-timeout=2 - clear either on input or after timeout
after-input=t after-timeout=0 - clear only when input is available:
this has an advantage that user has control
when
wants to clear message immediately on
keypress;
after-input=nil after-timeout=2 - clear only after timeout, not on input:
this has an advantage that user will never
miss
a message while typing in the minibuffer,
the message will stay for the specified number
of seconds regardless of input,
so user will have a chance to read it
Do all these variants make sense?
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, (continued)
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/16
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/16
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Dmitry Gutov, 2019/12/16
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, HaiJun Zhang, 2019/12/17
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/17
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/17
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, HaiJun Zhang, 2019/12/17
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/17
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/17
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/18
- bug#38457: 27.0.50; dabbrev-expand regression due to message change,
Juri Linkov <=
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/19
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/19
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Dmitry Gutov, 2019/12/19
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/19
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/20
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/19
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/20
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/21
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Eli Zaretskii, 2019/12/20
- bug#38457: 27.0.50; dabbrev-expand regression due to message change, Juri Linkov, 2019/12/21