bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown

[ynyaaa@gmail.com]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: ynyaaa@gmail.com
>> Cc: bug-gnu-emacs@gnu.org, 38645@debbugs.gnu.org
>> Date: Wed, 18 Dec 2019 19:52:44 +0900
>> 
>> Evaluate the form below and type 3 2 1, minibuffer window shrinks each
>> time. This behavior is inconsistent with read-string.
>> To check echo area contents just before read-string, type 3 4
>> and the tmp variable value is nil, which indicates that the echo area
>> has been cleared without shrinking the minibuffer window.
>> 
>> (let ((buf (generate-new-buffer "tmp"))
>>       (map (make-sparse-keymap)))
>>   (switch-to-buffer buf)
>>   (define-key map "1" (lambda () (interactive) (message "1")))
>>   (define-key map "2" (lambda () (interactive) (message "a\nb")))
>>   (define-key map "3" (lambda () (interactive) (message "A\nB\nC")))
>>   (define-key map "4" (lambda () (interactive)
>>                         (let ((tmp (current-message)))
>>                           (read-string "input: ")
>>                           (message "tmp: %s" tmp))))
>>   (use-local-map map))
>> 
>> 
>> By the way, read-string with empty PROMPT make the minibuffer window
>> shrink.
>> 
>> (progn
>>   (message "1\n2")
>>   (read-string ""))
>> 
>> Also it make the window shrink when all the minibuffer content is
>> deleted, even though read-string is not finished.
>> 
>> M-: (read-string "") RET
>> C-q C-j
>> C-q C-j
>> DEL
>> DEL
>
> I still fail to see the problem in these use cases.  Is the problem
> that from your POV the behavior wrt shrinking the mini-window happens
> sometimes, but not always?  If so, this is not a bug: by default Emacs
> does not try too hard to do so, although when a command finishes and
> Emacs runs a full redisplay cycle, it usually does shrink it.  If you
> set resize-mini-windows to t, it tries harder, and will shrink in many
> cases even in the middle of a running command.
>
> Also please keep in mind that the mini-window shows not only the echo
> area, but also the minibuffer (when it's active), so the fact that the
> echo-area message has been cleared does not yet mean the mini-window
> can be shrunk -- if the minibuffer is active, it usually won't be.
>
> At this point please tell if you have real-life use cases where this
> behavior causes real problems, like concealing some part of the
> echo-area message, and if so, please describe those real-life use
> cases.  If this is just about consistency, I tend not to touch this
> area of the display engine, as it is somewhat delicate and easy to
> break.
>
> Thanks.

With (setq resize-mini-windows t), the key sequence below shows message
in one-line window. Then input motion commands and the minibuffer is
redisplayed in one-line window. Eval: prompt is hidden.

M-:
C-q C-j
?a
C-x C-e