bug#38791: 27.0.60; Multiline mini-window fails to resize after clearing message

bug#38791: 27.0.60; Multiline mini-window fails to resize after clearing message

[Eli Zaretskii]

To reproduce from "emacs -Q":

 . Turn off global-eldoc-mode, which triggers redisplay and can hide
   this bug:

     M-x global-eldoc-mode RET

 . Set resize-mini-windows to t.

 . Type into *scratch*:

   (message "a\nb\nc")

   and press "C-x C-e" to evaluate the call to 'message'.  This will
   show a 3-line message in the echo area, and the mini-window will
   resize to show all the 3 lines.

 . Press any key, for example C-b.  This clears the echo area, but the
   mini-window is not resized back to a single line, although the value
   of resize-mini-windows is t.

This is a regression, because in Emacs 26 this works as expected.

The patch to fix this is below.  It reverts a small part of commit
8e0ebb9, which inadvertently changed the logic in grow_mini_window.
The problem in this case was that old_height + delta evaluated to
zero, but instead of limiting the result to the equivalent of 1 line,
the code did nothing.

diff --git a/src/window.c b/src/window.c
index c52a8ca285..1962e07f8d 100644
--- a/src/window.c
+++ b/src/window.c
@@ -5229,10 +5229,15 @@ grow_mini_window (struct window *w, int delta)
 {
   struct frame *f = XFRAME (w->frame);
   int old_height = window_body_height (w, true);
+  int min_height = FRAME_LINE_HEIGHT (f);
 
   eassert (MINI_WINDOW_P (w));
 
-  if ((delta != 0) && (old_height + delta >= FRAME_LINE_HEIGHT (f)))
+  /* Never shrink mini-window to less than its minimum height.  */
+  if (old_height + delta < min_height)
+    delta = old_height > min_height ? min_height - old_height : 0;
+
+  if (delta != 0)
     {
       Lisp_Object root = FRAME_ROOT_WINDOW (f);
       struct window *r = XWINDOW (root);



In GNU Emacs 27.0.60 (build 15, i686-pc-mingw32)
 of 2019-12-29 built on HOME-C4E4A596F7
Repository revision: aa0c679f484347d20ab6f7c0f75f32f5e360cb89
Repository branch: emacs-27
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 50621 11136)
 (symbols 48 7172 1)
 (strings 16 18826 2216)
 (string-bytes 1 531767)
 (vectors 16 9418)
 (vector-slots 8 126838 7876)
 (floats 8 21 333)
 (intervals 40 258 20)
 (buffers 888 11))

bug#38791: 27.0.60; Multiline mini-window fails to resize after clearing message

[martin rudalics]

 > This is a regression, because in Emacs 26 this works as expected.
 >
 > The patch to fix this is below.  It reverts a small part of commit
 > 8e0ebb9, which inadvertently changed the logic in grow_mini_window.
 > The problem in this case was that old_height + delta evaluated to
 > zero, but instead of limiting the result to the equivalent of 1 line,
 > the code did nothing.

It apparently never entered my mind that WINDOW_BOX_TEXT_HEIGHT might
mean something different from the height of that window's buffer text.
Shameful.

Thanks for the fix, martin

bug#38791: 27.0.60; Multiline mini-window fails to resize after clearing message

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 29 Dec 2019 19:33:52 +0100
> 
>  > This is a regression, because in Emacs 26 this works as expected.
>  >
>  > The patch to fix this is below.  It reverts a small part of commit
>  > 8e0ebb9, which inadvertently changed the logic in grow_mini_window.
>  > The problem in this case was that old_height + delta evaluated to
>  > zero, but instead of limiting the result to the equivalent of 1 line,
>  > the code did nothing.
> 
> It apparently never entered my mind that WINDOW_BOX_TEXT_HEIGHT might
> mean something different from the height of that window's buffer text.
> Shameful.

Well, the name is ambiguous.

I installed the fix, and I'm closing the bug report.

bug#38791: 27.0.60; Multiline mini-window fails to resize after clearing message

[martin rudalics]

 >> It apparently never entered my mind that WINDOW_BOX_TEXT_HEIGHT might
 >> mean something different from the height of that window's buffer text.
 >> Shameful.
 >
 > Well, the name is ambiguous.

I'd eventually want to keep only one function among
WINDOW_BOX_TEXT_HEIGHT, window_box_height and window_body_height.  But
before that we'd have to sort out which one to keep among
CURRENT_{MODE,HEADER,TAB}_LINE_HEIGHT,
WINDOW_{MODE,HEADER,TAB}_LINE_HEIGHT and the calculations done in
window_box_height.  Together with window_wants_{mode,header,tab}_line
I'm afraid that we have some circular definition here which is also
confirmed by the fact that using CURRENT_{MODE,HEADER,TAB}_LINE_HEIGHT
within other macros is usually frowned upon by gcc complaining about
missing sequence points due to the

((W)->{mode,header,tab}_line_height

assignments.  Parts of that dilemma also show up in miscalculating the
heights of the vertical scroll bar window as sketched in the thread on
Bug#38181.

In either case the bug you fixed here was all mine when I started to
squeeze the earlier shrink/grow call sequence into a single grow call.

 > I installed the fix, and I'm closing the bug report.

Thanks again, martin