bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: 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@debbugs.gnu.org
> From: martin rudalics <rudalics@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);





reply via email to

[Prev in Thread] Current Thread [Next in Thread]