GNU bug report logs - #38791
27.0.60; Multiline mini-window fails to resize after clearing message

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38791 in the body.
You can then email your comments to 38791 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: 27.0.60; Multiline mini-window fails to resize after clearing message
Date: Sun, 29 Dec 2019 16:27:15 +0200

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

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, bug-gnu-emacs <at> gnu.org
Subject: Re: 27.0.60; Multiline mini-window fails to resize after clearing
 message
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.

Thanks for the fix, martin

Message #13 received at 38791-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38791-done <at> debbugs.gnu.org
Subject: Re: 27.0.60; Multiline mini-window fails to resize after clearing
 message
Date: Mon, 30 Dec 2019 17:56:07 +0200

> From: martin rudalics <rudalics <at> 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.

Message #16 received at 38791-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38791-done <at> debbugs.gnu.org
Subject: Re: 27.0.60; Multiline mini-window fails to resize after clearing
 message
Date: Mon, 30 Dec 2019 18:54:14 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.