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

[Juri Linkov]

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