GNU bug report logs - #60015
29.0.60; multi-line messages truncated in non-selected minibuffer

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 60015 in the body.
You can then email your comments to 60015 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: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; multi-line messages truncated in non-selected minibuffer
Date: Mon, 12 Dec 2022 20:03:41 +0200

[Message part 1 (text/plain, inline)]

0. emacs -Q
1. (run-with-timer 5 5 'message "abc\ndef")
2. then activate the minibuffer and switch back to the original buffer
3. after some time observe that only the first line of the multi-line message
   is displayed in the minibuffer

I don't know where this problem comes from, but it's impossible to use
edebug to debug minibuffer-related bugs while the minibuffer is active,
because only an old message is displayed, not the most recent,
when using set-multi-message to collect messages.  So here is
at least the fix for set-multi-message:

[set-multi-message.patch (text/x-diff, inline)]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index cfdf2b43f42..36553eca1ad 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -914,6 +914,11 @@ set-multi-message
   "Return recent messages as one string to display in the echo area.
 Note that this feature works best only when `resize-mini-windows'
 is at its default value `grow-only'."
+  (if (and (active-minibuffer-window) (not (minibufferp)))
+      ;; Multi-line messages are limited to one line only
+      ;; when the minibuffer window is active and not selected.
+      ;; So don't return a multi-line string in this case:
+      message
     (let ((last-message (car multi-message-list)))
       (unless (and last-message (equal message (aref last-message 1)))
         (when last-message
@@ -931,7 +936,7 @@ set-multi-message
           (setf (nthcdr multi-message-max multi-message-list) nil)))
       (mapconcat (lambda (m) (aref m 1))
                  (reverse multi-message-list)
-               multi-message-separator)))
+                 multi-message-separator))))
 
 (defun clear-minibuffer-message ()
   "Clear minibuffer message.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60;
 multi-line messages truncated in non-selected minibuffer
Date: Mon, 12 Dec 2022 20:19:48 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Date: Mon, 12 Dec 2022 20:03:41 +0200
> 
> 0. emacs -Q
> 1. (run-with-timer 5 5 'message "abc\ndef")
> 2. then activate the minibuffer and switch back to the original buffer
> 3. after some time observe that only the first line of the multi-line message
>    is displayed in the minibuffer

Doesn't happen here (I waited for 2.5 minutes).  Is the recipe
complete and exact?  Does it perhaps matter how do you "switch back to
the original buffer"?  (I used a mouse click.)

When the problem happens, what do you see in *Messages*?  Anything
other that "abc\ndef"?

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in
 non-selected minibuffer
Date: Mon, 12 Dec 2022 20:37:05 +0200

>> 1. (run-with-timer 5 5 'message "abc\ndef")
>> 2. then activate the minibuffer and switch back to the original buffer
>> 3. after some time observe that only the first line of the multi-line message
>>    is displayed in the minibuffer
>
> Doesn't happen here (I waited for 2.5 minutes).  Is the recipe
> complete and exact?  Does it perhaps matter how do you "switch back to
> the original buffer"?  (I used a mouse click.)

It's essential to ensure that the height of the minibuffer/echo area
initially is not more than 1 line.  Otherwise, when it's already resized
to fit multi-line messages, then all lines are displayed.

> When the problem happens, what do you see in *Messages*?  Anything
> other that "abc\ndef"?

Only the first line "abc" is displayed in the minibuffer
as the minibuffer message.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in
 non-selected minibuffer
Date: Mon, 12 Dec 2022 21:20:49 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 60015 <at> debbugs.gnu.org
> Date: Mon, 12 Dec 2022 20:37:05 +0200
> 
> >> 1. (run-with-timer 5 5 'message "abc\ndef")
> >> 2. then activate the minibuffer and switch back to the original buffer
> >> 3. after some time observe that only the first line of the multi-line message
> >>    is displayed in the minibuffer
> >
> > Doesn't happen here (I waited for 2.5 minutes).  Is the recipe
> > complete and exact?  Does it perhaps matter how do you "switch back to
> > the original buffer"?  (I used a mouse click.)
> 
> It's essential to ensure that the height of the minibuffer/echo area
> initially is not more than 1 line.

That's so by default, so "emacs -Q" should ensure that.  Right?

> > When the problem happens, what do you see in *Messages*?  Anything
> > other that "abc\ndef"?
> 
> Only the first line "abc" is displayed in the minibuffer
> as the minibuffer message.

I asked about the *Messages* buffer, not about the minibuffer.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in
 non-selected minibuffer
Date: Tue, 13 Dec 2022 19:20:06 +0200

>> >> 1. (run-with-timer 5 5 'message "abc\ndef")
>> >> 2. then activate the minibuffer and switch back to the original buffer
>> >> 3. after some time observe that only the first line of the multi-line message
>> >>    is displayed in the minibuffer
>> >
>> > Doesn't happen here (I waited for 2.5 minutes).  Is the recipe
>> > complete and exact?  Does it perhaps matter how do you "switch back to
>> > the original buffer"?  (I used a mouse click.)
>>
>> It's essential to ensure that the height of the minibuffer/echo area
>> initially is not more than 1 line.
>
> That's so by default, so "emacs -Q" should ensure that.  Right?

Evaluating the first line above resizes the minibuffer,
and the timer resizes the minibuffer, so it's difficult
to find a moment when it's exactly 1 line high.
I have no idea how to simplify this test case.

>> > When the problem happens, what do you see in *Messages*?  Anything
>> > other that "abc\ndef"?
>>
>> Only the first line "abc" is displayed in the minibuffer
>> as the minibuffer message.
>
> I asked about the *Messages* buffer, not about the minibuffer.

Sorry.  The *Messages* buffer shows all lines of the multi-line string.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in
 non-selected minibuffer
Date: Tue, 13 Dec 2022 19:44:17 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 60015 <at> debbugs.gnu.org
> Date: Tue, 13 Dec 2022 19:20:06 +0200
> 
> >> > Doesn't happen here (I waited for 2.5 minutes).  Is the recipe
> >> > complete and exact?  Does it perhaps matter how do you "switch back to
> >> > the original buffer"?  (I used a mouse click.)
> >>
> >> It's essential to ensure that the height of the minibuffer/echo area
> >> initially is not more than 1 line.
> >
> > That's so by default, so "emacs -Q" should ensure that.  Right?
> 
> Evaluating the first line above resizes the minibuffer,
> and the timer resizes the minibuffer, so it's difficult
> to find a moment when it's exactly 1 line high.

You said "initially", so I thought you were talking about what
happens before the recipe is started.

Are you saying that you see the echo-area go down to 1 line _after_
the timer is started?  If so, to unlock this puzzle we need to
understand what causes the mini-window to resize back to 1 line.  The
default value of resize-mini-windows is 'grow-only', so it isn't
supposed to shrink back to 1 line.

> >> > When the problem happens, what do you see in *Messages*?  Anything
> >> > other that "abc\ndef"?
> >>
> >> Only the first line "abc" is displayed in the minibuffer
> >> as the minibuffer message.
> >
> > I asked about the *Messages* buffer, not about the minibuffer.
> 
> Sorry.  The *Messages* buffer shows all lines of the multi-line string.

And nothing else?  I hoped you will see there something that would
explain why the mini-window resized back to 1 line.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in
 non-selected minibuffer
Date: Tue, 13 Dec 2022 19:56:55 +0200

> Are you saying that you see the echo-area go down to 1 line _after_
> the timer is started?  If so, to unlock this puzzle we need to
> understand what causes the mini-window to resize back to 1 line.  The
> default value of resize-mini-windows is 'grow-only', so it isn't
> supposed to shrink back to 1 line.

The echo-area doesn't go down to 1 line automatically.  You need to force it
to have the height of 1 line to be able to see the bug.  I use C-g to resize
it back to 1 line.  Then multi-line message from the timer displays only
the first line.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in
 non-selected minibuffer
Date: Thu, 15 Dec 2022 09:44:42 +0200

Here is a better test case.  Please evaluate:

(progn
  (keymap-global-set "C-c C-c" (lambda () (interactive) (message "abc\ndef")))
  nil)

Then the bug can be reproduced with just these keys:

M-x
C-x o
C-c C-c

Only the top line is displayed in the minibuffer.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in non-selected
 minibuffer
Date: Thu, 15 Dec 2022 11:18:15 +0100

> Here is a better test case.  Please evaluate:
>
> (progn
>    (keymap-global-set "C-c C-c" (lambda () (interactive) (message "abc\ndef")))
>    nil)
>
> Then the bug can be reproduced with just these keys:
>
> M-x
> C-x o
> C-c C-c
>
> Only the top line is displayed in the minibuffer.

This is caused by resize_echo_area_exactly in xdisp.c.  If you replace

      Lisp_Object resize_exactly = (minibuf_level == 0 ? Qt : Qnil);

with

      Lisp_Object resize_exactly = Qt;

the echo area gets resized.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 60015 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in non-selected
 minibuffer
Date: Thu, 15 Dec 2022 15:36:24 +0200

> Date: Thu, 15 Dec 2022 11:18:15 +0100
> Cc: 60015 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Here is a better test case.  Please evaluate:
>  >
>  > (progn
>  >    (keymap-global-set "C-c C-c" (lambda () (interactive) (message "abc\ndef")))
>  >    nil)
>  >
>  > Then the bug can be reproduced with just these keys:
>  >
>  > M-x
>  > C-x o
>  > C-c C-c
>  >
>  > Only the top line is displayed in the minibuffer.
> 
> This is caused by resize_echo_area_exactly in xdisp.c.  If you replace
> 
>        Lisp_Object resize_exactly = (minibuf_level == 0 ? Qt : Qnil);
> 
> with
> 
>        Lisp_Object resize_exactly = Qt;
> 
> the echo area gets resized.

Are you sure this is the reason and the possible fix?  The commentary
to resize_echo_area_exactly says:

  /* Resize the echo area window to exactly the size needed for the
     currently displayed message, if there is one.  If a mini-buffer
     is active, don't shrink it.  */

which makes a lot of sense.  And resize_mini_window, which does the
job and accepts the argument you suggest to make Qt always, has this
single place where it looks at that argument (called EXACT_P):

      if (EQ (Vresize_mini_windows, Qgrow_only))
	{
	  /* Let it grow only, until we display an empty message, in which
	     case the window shrinks again.  */
	  if (height > old_height)
	    grow_mini_window (w, height - old_height);
	  else if (height < old_height && (exact_p || BEGV == ZV))
	    shrink_mini_window (w);
	}

So this argument cannot have any effect on enlarging the mini-window,
only on shrinking it.  Or am I missing something?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rudalics <at> gmx.at
Cc: 60015 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#60015: 29.0.60;
 multi-line messages truncated in non-selected minibuffer
Date: Thu, 15 Dec 2022 16:30:03 +0200

> Cc: 60015 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Thu, 15 Dec 2022 15:36:24 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > This is caused by resize_echo_area_exactly in xdisp.c.  If you replace
> > 
> >        Lisp_Object resize_exactly = (minibuf_level == 0 ? Qt : Qnil);
> > 
> > with
> > 
> >        Lisp_Object resize_exactly = Qt;
> > 
> > the echo area gets resized.
> 
> Are you sure this is the reason and the possible fix?

AFAICT, resize_echo_area_exactly doesn't get called in this scenario.
Which might be part of the problem.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60015 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in non-selected
 minibuffer
Date: Thu, 15 Dec 2022 16:07:42 +0100

> Are you sure this is the reason and the possible fix?

It's neither.

> AFAICT, resize_echo_area_exactly doesn't get called in this scenario.
> Which might be part of the problem.

What I see is that

  if (!NILP (echo_area_buffer[0]) || minibuf_level == 0)

evaluates to false in echo_area_display.  So the problem seems to be
with 'set-message-functions' and there I'm lost.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60015 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in non-selected
 minibuffer
Date: Thu, 15 Dec 2022 16:12:05 +0100

> So the problem seems to be
> with 'set-message-functions' and there I'm lost.

BTW

(setq set-message-functions nil)

fixes it here.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 60015 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in non-selected
 minibuffer
Date: Thu, 15 Dec 2022 17:30:13 +0200

> Date: Thu, 15 Dec 2022 16:12:05 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 60015 <at> debbugs.gnu.org, juri <at> linkov.net
> 
>  > So the problem seems to be
>  > with 'set-message-functions' and there I'm lost.
> 
> BTW
> 
> (setq set-message-functions nil)
> 
> fixes it here.

Of course.  Because then the temporary-message-shown-as-overlay
feature is disabled, and we show messages via xdisp.c code.  Like I
said: this particular issue happens because in this scenario
set-minibuffer-message bypasses the "normal" code in message3_nolog
which displays messages "normally".  We just add an overlay to the
minibuffer, and expect redisplay_window to resize the mini-window as
part of its redrawing all the windows.  But redisplay_window doesn't.

Juri, does the patch below give good results?  It's a bit of overkill,
since the mini-window usually doesn't need any resizing, but maybe
that is not too bad.

If it seems to solve the problem, would you please run with this for a
couple of weeks, and report back if you see any problems?  If there
are no problems, I'll then install this on the emacs-29 branch.

diff --git a/src/xdisp.c b/src/xdisp.c
index d14cd46..45da496 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -19429,6 +19429,13 @@ redisplay_window (Lisp_Object window, bool just_this_one_p)
 	    blank_row (w, row, y);
 	  goto finish_scroll_bars;
 	}
+      else if (minibuf_level >= 1)
+	{
+	  /* We could have a message produced by set-minibuffer-message
+	     displayed in the mini-window as an overlay, so resize the
+	     mini-window if needed.  */
+	  resize_mini_window (w, false);
+	}
 
       clear_glyph_matrix (w->desired_matrix);
     }

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in non-selected
 minibuffer
Date: Thu, 15 Dec 2022 16:44:29 +0000

>
> Here is a better test case.  Please evaluate:
>
> (progn
>  (keymap-global-set "C-c C-c" (lambda () (interactive) (message "abc\ndef")))
>  nil)
>
> Then the bug can be reproduced with just these keys:
>
> M-x
> C-x o
> C-c C-c
>
> Only the top line is displayed in the minibuffer.
>

Is this not something that can be solved in set-minibuffer-message, like 
this:

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 6e42296e7ba..c10a6401180 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -817,6 +817,11 @@ set-minibuffer-message
                           ;; Make sure we can put-text-property.
                           (copy-sequence message)
                         (concat " [" message "]")))
+        (let ((window-lines (window-height minibuf-window))
+              (message-lines (length (split-string message "\n"))))
+          (when (> message-lines window-lines)
+            (with-selected-window minibuf-window
+              (enlarge-window (- message-lines window-lines)))))
         (unless (or (null minibuffer-message-properties)
                     ;; Don't overwrite the face properties the caller has set
                     (text-properties-at 0 message))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 60015 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in non-selected
 minibuffer
Date: Thu, 15 Dec 2022 19:03:30 +0200

> Date: Thu, 15 Dec 2022 16:44:29 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, 60015 <at> debbugs.gnu.org
> 
> Is this not something that can be solved in set-minibuffer-message, like 
> this:
> 
> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> index 6e42296e7ba..c10a6401180 100644
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -817,6 +817,11 @@ set-minibuffer-message
>                             ;; Make sure we can put-text-property.
>                             (copy-sequence message)
>                           (concat " [" message "]")))
> +        (let ((window-lines (window-height minibuf-window))
> +              (message-lines (length (split-string message "\n"))))
> +          (when (> message-lines window-lines)
> +            (with-selected-window minibuf-window
> +              (enlarge-window (- message-lines window-lines)))))
>           (unless (or (null minibuffer-message-properties)
>                       ;; Don't overwrite the face properties the caller has set
>                       (text-properties-at 0 message))

This won't catch the case of a single very long line (which wraps to
produce several screen lines).

Also, unconditionally enlarging the mini-window is not a good idea
because it might already be tall enough.  Try the above in the recipe
posted by Juri, but then type "C-c C-c" several times -- doesn't it
keep enlarging the mini-window with each "C-c C-c"?

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in
 non-selected minibuffer
Date: Thu, 15 Dec 2022 19:35:43 +0200

> Juri, does the patch below give good results?  It's a bit of overkill,
> since the mini-window usually doesn't need any resizing, but maybe
> that is not too bad.
>
> If it seems to solve the problem, would you please run with this for a
> couple of weeks, and report back if you see any problems?  If there
> are no problems, I'll then install this on the emacs-29 branch.

I'll test it for a while.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in
 non-selected minibuffer
Date: Thu, 15 Dec 2022 19:37:03 +0200

>> Is this not something that can be solved in set-minibuffer-message, like 
>> this:
>>
>> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
>> index 6e42296e7ba..c10a6401180 100644
>> --- a/lisp/minibuffer.el
>> +++ b/lisp/minibuffer.el
>> @@ -817,6 +817,11 @@ set-minibuffer-message
>>                             ;; Make sure we can put-text-property.
>>                             (copy-sequence message)
>>                           (concat " [" message "]")))
>> +        (let ((window-lines (window-height minibuf-window))
>> +              (message-lines (length (split-string message "\n"))))
>> +          (when (> message-lines window-lines)
>> +            (with-selected-window minibuf-window
>> +              (enlarge-window (- message-lines window-lines)))))
>>           (unless (or (null minibuffer-message-properties)
>>                       ;; Don't overwrite the face properties the caller has set
>>                       (text-properties-at 0 message))
>
> This won't catch the case of a single very long line (which wraps to
> produce several screen lines).

Testing shows that it doesn't handle wrapped lines.

> Also, unconditionally enlarging the mini-window is not a good idea
> because it might already be tall enough.  Try the above in the recipe
> posted by Juri, but then type "C-c C-c" several times -- doesn't it
> keep enlarging the mini-window with each "C-c C-c"?

But OTOH it doesn't keep enlarging the mini-window with each "C-c C-c".

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in non-selected
 minibuffer
Date: Thu, 15 Dec 2022 21:52:33 +0000

>>> +        (let ((window-lines (window-height minibuf-window))
>>> +              (message-lines (length (split-string message "\n"))))
>>> +          (when (> message-lines window-lines)
>>> +            (with-selected-window minibuf-window
>>> +              (enlarge-window (- message-lines window-lines)))))
>>
>> This won't catch the case of a single very long line (which wraps to 
>> produce several screen lines).
>
> Testing shows that it doesn't handle wrapped lines.
>

Indeed, but that wasn't part of your problem statement ;-)

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 60015 <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in
 non-selected minibuffer
Date: Sat, 17 Dec 2022 19:39:49 +0200

> Juri, does the patch below give good results?  It's a bit of overkill,
> since the mini-window usually doesn't need any resizing, but maybe
> that is not too bad.
>
> If it seems to solve the problem, would you please run with this for a
> couple of weeks, and report back if you see any problems?  If there
> are no problems, I'll then install this on the emacs-29 branch.
>
> diff --git a/src/xdisp.c b/src/xdisp.c
> index d14cd46..45da496 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -19429,6 +19429,13 @@ redisplay_window (Lisp_Object window, bool just_this_one_p)
>  	    blank_row (w, row, y);
>  	  goto finish_scroll_bars;
>  	}
> +      else if (minibuf_level >= 1)
> +	{
> +	  /* We could have a message produced by set-minibuffer-message
> +	     displayed in the mini-window as an overlay, so resize the
> +	     mini-window if needed.  */
> +	  resize_mini_window (w, false);
> +	}

I tested it for a while and see no problems with it.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 60015-done <at> debbugs.gnu.org
Subject: Re: bug#60015: 29.0.60; multi-line messages truncated in
 non-selected minibuffer
Date: Sat, 17 Dec 2022 20:45:34 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: martin rudalics <rudalics <at> gmx.at>,  60015 <at> debbugs.gnu.org
> Date: Sat, 17 Dec 2022 19:39:49 +0200
> 
> > Juri, does the patch below give good results?  It's a bit of overkill,
> > since the mini-window usually doesn't need any resizing, but maybe
> > that is not too bad.
> >
> > If it seems to solve the problem, would you please run with this for a
> > couple of weeks, and report back if you see any problems?  If there
> > are no problems, I'll then install this on the emacs-29 branch.
> >
> > diff --git a/src/xdisp.c b/src/xdisp.c
> > index d14cd46..45da496 100644
> > --- a/src/xdisp.c
> > +++ b/src/xdisp.c
> > @@ -19429,6 +19429,13 @@ redisplay_window (Lisp_Object window, bool just_this_one_p)
> >  	    blank_row (w, row, y);
> >  	  goto finish_scroll_bars;
> >  	}
> > +      else if (minibuf_level >= 1)
> > +	{
> > +	  /* We could have a message produced by set-minibuffer-message
> > +	     displayed in the mini-window as an overlay, so resize the
> > +	     mini-window if needed.  */
> > +	  resize_mini_window (w, false);
> > +	}
> 
> I tested it for a while and see no problems with it.

Thanks, installed on the emacs-29 branch, and closing this bug.

Previous Next

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