bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: set-multi-message.patch --]
[-- Type: text/x-diff, Size: 1121 bytes --]

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.

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Eli Zaretskii]

> From: Juri Linkov <juri@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"?

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Juri Linkov]

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

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 60015@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.

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Juri Linkov]

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

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 60015@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.

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Juri Linkov]

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

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Juri Linkov]

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.

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[martin rudalics]

 > 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

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Eli Zaretskii]

> Date: Thu, 15 Dec 2022 11:18:15 +0100
> Cc: 60015@debbugs.gnu.org
> From: martin rudalics <rudalics@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?

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Eli Zaretskii]

> Cc: 60015@debbugs.gnu.org, juri@linkov.net
> Date: Thu, 15 Dec 2022 15:36:24 +0200
> From: Eli Zaretskii <eliz@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.

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[martin rudalics]

 > 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

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[martin rudalics]

 > 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

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Eli Zaretskii]

> Date: Thu, 15 Dec 2022 16:12:05 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 60015@debbugs.gnu.org, juri@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);
     }

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Juri Linkov]

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

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Juri Linkov]

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

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: martin rudalics <rudalics@gmx.at>,  60015@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.

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Gregory Heytings]

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

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Eli Zaretskii]

> Date: Thu, 15 Dec 2022 16:44:29 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 60015@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"?

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Juri Linkov]

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

bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Gregory Heytings]

>>> +        (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 ;-)