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

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 38645 in the body.
You can then email your comments to 38645 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: ynyaaa <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3;
 minibuffer input is called with multi-line window when multi-line
 message is shown
Date: Tue, 17 Dec 2019 15:49:17 +0900

Evaluating the form below, the minibuffer window has 2-line height.

(progn
  (message "1\n2")
  (read-string "input: "))


In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 6.3.9600
Recent messages:

C-h C-b is undefined

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

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 seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util japan-util 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 menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame 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 minibuffer 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 99630 10477)
 (symbols 48 20226 1)
 (miscs 40 42 193)
 (strings 32 29779 1438)
 (string-bytes 1 765275)
 (vectors 16 14542)
 (vector-slots 8 572211 11846)
 (floats 8 51 191)
 (intervals 56 269 16)
 (buffers 992 12))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org,ynyaaa <at> gmail.com,38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3;
 minibuffer input is called with multi-line window when multi-line
 message is shown
Date: Tue, 17 Dec 2019 09:41:10 +0200

On December 17, 2019 8:49:17 AM GMT+02:00, ynyaaa <at> gmail.com wrote:
> 
> Evaluating the form below, the minibuffer window has 2-line height.
> 
> (progn
>   (message "1\n2")
>   (read-string "input: "))


That's a feature: by default the mini-window only grows automatically, and doesn't get reset to its original 1 line until the echo area is cleared.  If you don't like this, customize resize-mini-windows to the value t, or bind it temporarily while running code such as in the recipe.

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

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org, 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3;
 minibuffer input is called with multi-line window when multi-line
 message is shown
Date: Tue, 17 Dec 2019 20:55:48 +0900

Eli Zaretskii <eliz <at> gnu.org> writes:

> On December 17, 2019 8:49:17 AM GMT+02:00, ynyaaa <at> gmail.com wrote:
>> 
>> Evaluating the form below, the minibuffer window has 2-line height.
>> 
>> (progn
>>   (message "1\n2")
>>   (read-string "input: "))
>
>
> That's a feature: by default the mini-window only grows automatically,
> and doesn't get reset to its original 1 line until the echo area is
> cleared.  If you don't like this, customize resize-mini-windows to the
> value t, or bind it temporarily while running code such as in the
> recipe.

This may happen with unrelated commands.
Commands below shows an example.
Please input M-x as one key event, not ESC x.

M-: "1\n2" RET
M-x

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: bug-gnu-emacs <at> gnu.org, 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3;
 minibuffer input is called with multi-line window when multi-line
 message is shown
Date: Tue, 17 Dec 2019 14:07:20 +0200

On December 17, 2019 1:55:48 PM GMT+02:00, ynyaaa <at> gmail.com wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > On December 17, 2019 8:49:17 AM GMT+02:00, ynyaaa <at> gmail.com wrote:
> >> 
> 
> > That's a feature: by default the mini-window only grows
> automatically,
> > and doesn't get reset to its original 1 line until the echo area is
> > cleared.  If you don't like this, customize resize-mini-windows to
> the
> > value t, or bind it temporarily while running code such as in the
> > recipe.
> 
> This may happen with unrelated commands.
> Commands below shows an example.
> Please input M-x as one key event, not ESC x.
> 
> M-: "1\n2" RET
> M-x

When I type this with resize-mini-windows set to t, typing M-x causes the mini-window to shrink back to its original one-line height.  So I don't think I understand the complaint.

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

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org, 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3;
 minibuffer input is called with multi-line window when multi-line
 message is shown
Date: Wed, 18 Dec 2019 19:52:44 +0900

Eli Zaretskii <eliz <at> gnu.org> writes:
> On December 17, 2019 1:55:48 PM GMT+02:00, ynyaaa <at> gmail.com wrote:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > On December 17, 2019 8:49:17 AM GMT+02:00, ynyaaa <at> gmail.com wrote:
>> >> 
>> 
>> > That's a feature: by default the mini-window only grows
>> automatically,
>> > and doesn't get reset to its original 1 line until the echo area is
>> > cleared.  If you don't like this, customize resize-mini-windows to
>> the
>> > value t, or bind it temporarily while running code such as in the
>> > recipe.
>> 
>> This may happen with unrelated commands.
>> Commands below shows an example.
>> Please input M-x as one key event, not ESC x.
>> 
>> M-: "1\n2" RET
>> M-x
>
> When I type this with resize-mini-windows set to t, typing M-x causes
> the mini-window to shrink back to its original one-line height.  So I
> don't think I understand the complaint.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3;
 minibuffer input is called with multi-line window when multi-line
 message is shown
Date: Wed, 18 Dec 2019 18:31:48 +0200

> From: ynyaaa <at> gmail.com
> Cc: bug-gnu-emacs <at> gnu.org, 38645 <at> 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.

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

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3;
 minibuffer input is called with multi-line window when multi-line
 message is shown
Date: Fri, 20 Dec 2019 11:16:31 +0900

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: ynyaaa <at> gmail.com
>> Cc: bug-gnu-emacs <at> gnu.org, 38645 <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com, martin rudalics <rudalics <at> gmx.at>
Cc: 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3;
 minibuffer input is called with multi-line window when multi-line
 message is shown
Date: Thu, 26 Dec 2019 22:49:45 +0200

> From: ynyaaa <at> gmail.com
> Cc: 38645 <at> debbugs.gnu.org
> Date: Fri, 20 Dec 2019 11:16:31 +0900
> 
> 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

Martin, what do you think about the following fix?  Is it correct, and
if so, safe enough for the release branch?

diff --git a/src/xdisp.c b/src/xdisp.c
index 3080f8920a..438267350f 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11562,7 +11562,15 @@ resize_mini_window (struct window *w, bool exact_p)
 
       SET_MARKER_FROM_TEXT_POS (w->start, start);
 
-      if (EQ (Vresize_mini_windows, Qgrow_only))
+      if (EQ (Vresize_mini_windows, Qgrow_only)
+	  /* Don't automatically shrink the mini-window, even if
+	     resize-mini-windows is t, if we are displaying an
+	     echo-area message while the minibuffer is active.  */
+	  || (minibuf_level > 0
+	      && WINDOW_LIVE_P (minibuf_window)
+	      && XWINDOW (minibuf_window) == w
+	      && !NILP (echo_area_buffer[0])
+	      && EQ (echo_area_window, minibuf_window)))
 	{
 	  /* Let it grow only, until we display an empty message, in which
 	     case the window shrinks again.  */

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, ynyaaa <at> gmail.com
Cc: 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3; minibuffer input is called with multi-line
 window when multi-line message is shown
Date: Fri, 27 Dec 2019 10:12:33 +0100

> Martin, what do you think about the following fix?  Is it correct, and
> if so, safe enough for the release branch?

It seems "correct" in the sense that our doc of 'resize-mini-windows'
nowhere contradicts any such interpretation.  It should be "safe" in
the sense that failing to always resize the minibuffer window exactly
and falling back on 'grow-only' should not do any harm since otherwise
we'd have a bug in the 'grow-only' part of the code.

But I'm too silly to understand why the minibuffer window does not
re-grow in the first place after having shown the result of C-x C-e.
Can you enlighten me?

martin, who just noted that the recently added (to master)

      Lisp_Object str = build_string ("Command attempted to use minibuffer"
                                      "while in minibuffer");

produces

"Command attempted to use minibufferwhile in minibuffer"

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: ynyaaa <at> gmail.com, 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3; minibuffer input is called with multi-line
 window when multi-line message is shown
Date: Fri, 27 Dec 2019 11:21:59 +0200

> Cc: 38645 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 27 Dec 2019 10:12:33 +0100
> 
> But I'm too silly to understand why the minibuffer window does not
> re-grow in the first place after having shown the result of C-x C-e.
> Can you enlighten me?

Re-grow upon which event?  If you do nothing, the message from "C-x C-e"
stays displayed indefinitely.

If you mean why it doesn't re-grow upon some keystroke (which removes
the message), I guess we are lacking a call to
resize_echo_area_exactly in some place.

Regardless, I think keeping the prompt visible is a better behavior.
And yes, we should probably document this caveat, although I cannot
imagine what application would like the current behavior.

> martin, who just noted that the recently added (to master)
> 
>        Lisp_Object str = build_string ("Command attempted to use minibuffer"
>                                        "while in minibuffer");
> 
> produces
> 
> "Command attempted to use minibufferwhile in minibuffer"

Hope you've already fixed it.

Thanks.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ynyaaa <at> gmail.com, 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3; minibuffer input is called with multi-line
 window when multi-line message is shown
Date: Fri, 27 Dec 2019 10:46:57 +0100

>> But I'm too silly to understand why the minibuffer window does not
>> re-grow in the first place after having shown the result of C-x C-e.
>> Can you enlighten me?
>
> Re-grow upon which event?  If you do nothing, the message from "C-x C-e"
> stays displayed indefinitely.

Not here.  After a short pause I get the one line ?a back.

> If you mean why it doesn't re-grow upon some keystroke (which removes
> the message), I guess we are lacking a call to
> resize_echo_area_exactly in some place.

I guess so too.

> Regardless, I think keeping the prompt visible is a better behavior.

But while showing the result of C-x C-e (97 ...) it doesn't show any
prompt here, just an empty trailing line.  What am I missing?

> And yes, we should probably document this caveat, although I cannot
> imagine what application would like the current behavior.
>
>> martin, who just noted that the recently added (to master)
>>
>>         Lisp_Object str = build_string ("Command attempted to use minibuffer"
>>                                         "while in minibuffer");
>>
>> produces
>>
>> "Command attempted to use minibufferwhile in minibuffer"
>
> Hope you've already fixed it.

I cannot reliably push these days.  I have to first rebuild my git
environment and probably will wait with that until Glen has fixed the
copyright headers to avoid excessive re-compilations.  My machine is
getting a bit weak for so much work ...

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3; minibuffer input is called with multi-line
 window when multi-line message is shown
Date: Fri, 27 Dec 2019 12:29:56 +0200

> Cc: ynyaaa <at> gmail.com, 38645 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 27 Dec 2019 10:46:57 +0100
> 
>  >> martin, who just noted that the recently added (to master)
>  >>
>  >>         Lisp_Object str = build_string ("Command attempted to use minibuffer"
>  >>                                         "while in minibuffer");
>  >>
>  >> produces
>  >>
>  >> "Command attempted to use minibufferwhile in minibuffer"
>  >
>  > Hope you've already fixed it.
> 
> I cannot reliably push these days.

OK, pushed.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: ynyaaa <at> gmail.com, 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3; minibuffer input is called with multi-line
 window when multi-line message is shown
Date: Sun, 29 Dec 2019 16:15:28 +0200

> Cc: 38645 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 27 Dec 2019 10:12:33 +0100
> 
>  > Martin, what do you think about the following fix?  Is it correct, and
>  > if so, safe enough for the release branch?
> 
> It seems "correct" in the sense that our doc of 'resize-mini-windows'
> nowhere contradicts any such interpretation.  It should be "safe" in
> the sense that failing to always resize the minibuffer window exactly
> and falling back on 'grow-only' should not do any harm since otherwise
> we'd have a bug in the 'grow-only' part of the code.
> 
> But I'm too silly to understand why the minibuffer window does not
> re-grow in the first place after having shown the result of C-x C-e.
> Can you enlighten me?

I hope the following alternative patch will answer that question.
Comments are welcome.

diff --git a/src/keyboard.c b/src/keyboard.c
index 4cf1f64b48..a04f1f77de 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -1318,6 +1318,11 @@ command_loop_1 (void)
 	  message1 (0);
 	  safe_run_hooks (Qecho_area_clear_hook);
 
+	  /* We cleared the echo area, and the minibuffer will now
+	     show, so resize the mini-window in case the minibuffer
+	     needs more or less space than the echo area.  */
+	  resize_mini_window (XWINDOW (minibuf_window), false);
+
 	  unbind_to (count, Qnil);
 
 	  /* If a C-g came in before, treat it as input now.  */
@@ -2989,6 +2994,16 @@ read_char (int commandflag, Lisp_Object map,
 	{
 	  safe_run_hooks (Qecho_area_clear_hook);
 	  clear_message (1, 0);
+	  /* If we were showing the echo-area message on top of an
+	     active minibuffer, resize the mini-window, since the
+	     minibuffer may need more or less space than the echo area
+	     we've just wiped.  */
+	  if (minibuf_level
+	      && EQ (minibuf_window, echo_area_window)
+	      /* The case where minibuffer-message-timeout is a number
+		 was already handled near the beginning of this function.  */
+	      && !NUMBERP (Vminibuffer_message_timeout))
+	    resize_mini_window (XWINDOW (minibuf_window), false);
 	}
       else if (FUNCTIONP (Vclear_message_function))
         clear_message (1, 0);

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ynyaaa <at> gmail.com, 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3; minibuffer input is called with multi-line
 window when multi-line message is shown
Date: Sun, 29 Dec 2019 19:33:43 +0100

> I hope the following alternative patch will answer that question.

It cleanly fixes the OP's problem.  Did you check whether any of the
other clear_message calls would need a similar treatment?

> +	      /* The case where minibuffer-message-timeout is a number
> +		 was already handled near the beginning of this function.  */

Can you tell where?  I didn't find it.

Thanks, martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: ynyaaa <at> gmail.com, 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3; minibuffer input is called with multi-line
 window when multi-line message is shown
Date: Sun, 29 Dec 2019 20:50:09 +0200

> Cc: ynyaaa <at> gmail.com, 38645 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sun, 29 Dec 2019 19:33:43 +0100
> 
>  > I hope the following alternative patch will answer that question.
> 
> It cleanly fixes the OP's problem.  Did you check whether any of the
> other clear_message calls would need a similar treatment?

Which ones?

>  > +	      /* The case where minibuffer-message-timeout is a number
>  > +		 was already handled near the beginning of this function.  */
> 
> Can you tell where?  I didn't find it.

Oops, sorry, it's at the beginning of command_loop_1.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ynyaaa <at> gmail.com, 38645 <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3; minibuffer input is called with multi-line
 window when multi-line message is shown
Date: Sun, 29 Dec 2019 20:30:47 +0100

>> Did you check whether any of the
>> other clear_message calls would need a similar treatment?
>
> Which ones?

Maybe the last one in read_char itself.  But I don't understand well what
we are doing there.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: ynyaaa <at> gmail.com, 38645-done <at> debbugs.gnu.org
Subject: Re: bug#38645: 26.3; minibuffer input is called with multi-line
 window when multi-line message is shown
Date: Mon, 30 Dec 2019 18:07:02 +0200

> Cc: ynyaaa <at> gmail.com, 38645 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sun, 29 Dec 2019 20:30:47 +0100
> 
>  >> Did you check whether any of the
>  >> other clear_message calls would need a similar treatment?
>  >
>  > Which ones?
> 
> Maybe the last one in read_char itself.  But I don't understand well what
> we are doing there.

We are evidently clearing the echo area if the input method left
something there.  But I couldn't create a situation where there was
anything left to do after the input method finished its job, not by
turning on an input method in the active minibuffer.  Quail has its
own ideas about handling this situation; see quail-minibuffer-message
and quail-show-guidance.  In particular, it arranges for the guidance
to appear on the second line of the mini-window (the first one being
where you type at the prompt), and never shows more than one line of
candidates for input there (you need to scroll with up- and
down-arrows).  And when input is done, the mini-window resizes back.

So if someone knows how to trigger a mini-window resizing problems
related to input methods, please show a recipe (and reopen the bug).

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

Thanks for the feedback.

Previous Next

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