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

[Eli Zaretskii <eliz@gnu.org>]

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