bug#23124: Two minibuffer resize related bugs

bug#23124: Two minibuffer resize related bugs

[martin rudalics]

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

Sorry for the slightly contrived way these bugs are described.  I'm
working on them already for a couple of days and even smallest changes
to the scenario below makes them disappear.  To reproduce proceed as
follows:

(1) Save the attached foo.el file somewhere and make its first line match
     the location where you stored it.

(2) Start Emacs with the options -Q and -l to load foo.el.

(3) Type C-x 5 2.

(4) Go back to the initial frame, move to the end of the last non-empty
     line after ";; (bar)" and type C-x C-e.

At this moment "nothing" happens here (Bug#1).  When I now switch (via
Alt TAB) to the new frame (the one created via C-x 5 2), the message
appears there.  When I now type C-p in the new frame, the minibuffer
window shrinks back but the space previously occupied by the modeline of
the window above is not redrawn, hence I get two modelines above each
other (Bug#2).

Bug#1 can be observed here on the Gtk3, Lucid and Windows builds, Bug#2
only on Lucid and Windows.  Bugs appear for both, Emacs-25 and master.

Note that Bug#1 does not appear, for example, when I display a one line
message, when the new frame displays a different buffer, or when point
in the new frame is not a EOB.

I should be eventually able to track this down but if someone beats me
to it or has any ideas ...

martin

[-- Attachment #2: foo.el --]
[-- Type: application/emacs-lisp, Size: 4207 bytes --]

bug#23124: Two minibuffer resize related bugs

[Eli Zaretskii]

> Date: Sun, 27 Mar 2016 17:34:12 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> (1) Save the attached foo.el file somewhere and make its first line match
>      the location where you stored it.
> 
> (2) Start Emacs with the options -Q and -l to load foo.el.
> 
> (3) Type C-x 5 2.
> 
> (4) Go back to the initial frame, move to the end of the last non-empty
>      line after ";; (bar)" and type C-x C-e.
> 
> At this moment "nothing" happens here (Bug#1).  When I now switch (via
> Alt TAB) to the new frame (the one created via C-x 5 2), the message
> appears there.  When I now type C-p in the new frame, the minibuffer
> window shrinks back but the space previously occupied by the modeline of
> the window above is not redrawn, hence I get two modelines above each
> other (Bug#2).

Let's start with a much simpler reproducer:

  . emacs -Q
  . Type "C-x" and wait until you see "C-x-" in the echo area
  . Type "5 2"

Result: a new frame is displayed, with both frames showing the
"C-x 5 2" echo, which already sounds like a bug (only one frame should
show it).

Now type "C-p" -- only one of the two echo messages will disappear,
the one in the non-selected window stays put.

This didn't happen in Emacs 24.5, where the "C-x 5 2" echo is first
cleared, and then redisplayed after the new frame is created.

According to my testing, this problem appeared between Aug 31 and Sep
30 last year.

bug#23124: Two minibuffer resize related bugs

[martin rudalics]

 > Let's start with a much simpler reproducer:
 >
 >    . emacs -Q
 >    . Type "C-x" and wait until you see "C-x-" in the echo area
 >    . Type "5 2"
 >
 > Result: a new frame is displayed, with both frames showing the
 > "C-x 5 2" echo, which already sounds like a bug (only one frame should
 > show it).
 >
 > Now type "C-p" -- only one of the two echo messages will disappear,
 > the one in the non-selected window stays put.
 >
 > This didn't happen in Emacs 24.5, where the "C-x 5 2" echo is first
 > cleared, and then redisplayed after the new frame is created.

So far it's just queer but after returning to the first frame and typing
C-p there repeatedly, "C-x 5 2" remains fixed in that frame's echo area.

 > According to my testing, this problem appeared between Aug 31 and Sep
 > 30 last year.

I love bisecting.  Especially when copyright lines change.

My recipe can be obviously simplified as well:

. emacs -Q to get the first frame
. Type C-x 5 2 to get the second frame
. Evaluate (message "x\ny") in the first frame
. Type C-p in the second frame

martin

bug#23124: Two minibuffer resize related bugs

[Stephen Berman]

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

On Sun, 27 Mar 2016 22:51:56 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> Let's start with a much simpler reproducer:
>>
>>    . emacs -Q
>>    . Type "C-x" and wait until you see "C-x-" in the echo area
>>    . Type "5 2"
>>
>> Result: a new frame is displayed, with both frames showing the
>> "C-x 5 2" echo, which already sounds like a bug (only one frame should
>> show it).
>>
>> Now type "C-p" -- only one of the two echo messages will disappear,
>> the one in the non-selected window stays put.
>>
>> This didn't happen in Emacs 24.5, where the "C-x 5 2" echo is first
>> cleared, and then redisplayed after the new frame is created.
>
> So far it's just queer but after returning to the first frame and typing
> C-p there repeatedly, "C-x 5 2" remains fixed in that frame's echo area.
>
>> According to my testing, this problem appeared between Aug 31 and Sep
>> 30 last year.
>
> I love bisecting.  Especially when copyright lines change.
>
> My recipe can be obviously simplified as well:
>
> . emacs -Q to get the first frame
> . Type C-x 5 2 to get the second frame
> . Evaluate (message "x\ny") in the first frame
> . Type C-p in the second frame

I inadvertantly executed Eli's recipe yesterday and noticed an
additional oddity, seen in this screenshot (I didn't realize that that
recipe triggered it and since I couldn't otherwise reproduce the oddity
and had never seen it before, I didn't feel I had enough information to
file a bug):


[-- Attachment #2: minibuffer-2frame.png --]
[-- Type: image/png, Size: 4598 bytes --]

[-- Attachment #3: Type: text/plain, Size: 571 bytes --]


The extra space in the second frame's minibuffer remains for the life of
the frame AFAICT, at least I couldn't find any way to eliminate it.

This is on GNU Emacs 25.0.92.6 (x86_64-suse-linux-gnu, GTK+ Version
3.14.15) of 2016-03-26, emacs-repository-version
bc70fda2c9f93a30351c7c79a2b5763bbbd7bbc6, system-configuration-options
"--with-xwidgets 'CFLAGS=-Og -g3'", system-configuration-features XPM
JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XWIDGETS

Steve Berman

bug#23124: Two minibuffer resize related bugs

[martin rudalics]

 >>> Let's start with a much simpler reproducer:
 >>>
 >>>     . emacs -Q
 >>>     . Type "C-x" and wait until you see "C-x-" in the echo area
 >>>     . Type "5 2"
 >>>
[...]
 > I inadvertantly executed Eli's recipe yesterday and noticed an
 > additional oddity, seen in this screenshot (I didn't realize that that
 > recipe triggered it and since I couldn't otherwise reproduce the oddity
 > and had never seen it before, I didn't feel I had enough information to
 > file a bug):

I have no idea why C-x 5 2 should resize the echo area in the first
place.  Are you sure this happened with Eli's scenario above?

 > The extra space in the second frame's minibuffer remains for the life of
 > the frame AFAICT, at least I couldn't find any way to eliminate it.

Not even by displaying an empty or one-line message?

martin

bug#23124: Two minibuffer resize related bugs

[Stephen Berman]

On Mon, 28 Mar 2016 13:22:52 +0200 martin rudalics <rudalics@gmx.at> wrote:

>>>> Let's start with a much simpler reproducer:
>>>>
>>>>     . emacs -Q
>>>>     . Type "C-x" and wait until you see "C-x-" in the echo area
>>>>     . Type "5 2"
>>>>
> [...]
>> I inadvertantly executed Eli's recipe yesterday and noticed an
>> additional oddity, seen in this screenshot (I didn't realize that that
>> recipe triggered it and since I couldn't otherwise reproduce the oddity
>> and had never seen it before, I didn't feel I had enough information to
>> file a bug):
>
> I have no idea why C-x 5 2 should resize the echo area in the first
> place.  Are you sure this happened with Eli's scenario above?

Yes; I verified it before sending my post yesterday, and again just now.

>> The extra space in the second frame's minibuffer remains for the life of
>> the frame AFAICT, at least I couldn't find any way to eliminate it.
>
> Not even by displaying an empty or one-line message?

`M-: (message "")' has no effect, nor anything else I've tried
(e.g. `C-x 2 C-x 1', `C-x 3 C-x 1').  

It does, however, appear to be the case that only the first `C-x 5 2'
has this effect: typing that key sequence from either the second frame
(with the wide echo area/minibuffer) or from the first frame (with the
normal echo area/minibuffer) creates a frame with a normal echo area/
minibuffer.

Steve Berman

bug#23124: Two minibuffer resize related bugs

[martin rudalics]

 >> (1) Save the attached foo.el file somewhere and make its first line match
 >>       the location where you stored it.
 >>
 >> (2) Start Emacs with the options -Q and -l to load foo.el.
 >>
 >> (3) Type C-x 5 2.
 >>
 >> (4) Go back to the initial frame, move to the end of the last non-empty
 >>       line after ";; (bar)" and type C-x C-e.
 >>
 >> At this moment "nothing" happens here (Bug#1).  When I now switch (via
 >> Alt TAB) to the new frame (the one created via C-x 5 2), the message
 >> appears there.  When I now type C-p in the new frame, the minibuffer
 >> window shrinks back but the space previously occupied by the modeline of
 >> the window above is not redrawn, hence I get two modelines above each
 >> other (Bug#2).

I've now traced this behavior back to this

commit 9d6ec23f7d4f8fbbfdcea353c4b58e47f76a7342
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Sat Oct 24 18:54:15 2015 +0300

     Update frame title when redisplay scrolls selected window

     * src/xdisp.c (redisplay_window): Reconsider the frame's title
     when the mode-line of the frame's selected window needs to be
     updated.

In fact, removing the

       x_consider_frame_title (w->frame);

call from redisplay_window fixes both bugs here.

 > Let's start with a much simpler reproducer:
 >
 >    . emacs -Q
 >    . Type "C-x" and wait until you see "C-x-" in the echo area
 >    . Type "5 2"
 >
 > Result: a new frame is displayed, with both frames showing the
 > "C-x 5 2" echo, which already sounds like a bug (only one frame should
 > show it).
 >
 > Now type "C-p" -- only one of the two echo messages will disappear,
 > the one in the non-selected window stays put.
 >
 > This didn't happen in Emacs 24.5, where the "C-x 5 2" echo is first
 > cleared, and then redisplayed after the new frame is created.
 >
 > According to my testing, this problem appeared between Aug 31 and Sep
 > 30 last year.

This a different problem preceding the one I described.

martin

bug#23124: Two minibuffer resize related bugs

[martin rudalics]

 >> I have no idea why C-x 5 2 should resize the echo area in the first
 >> place.  Are you sure this happened with Eli's scenario above?
 >
 > Yes; I verified it before sending my post yesterday, and again just now.

I cannot reproduce the problem here.  Can you get a backtrace from where
grow_mini_window is called?

 > It does, however, appear to be the case that only the first `C-x 5 2'
 > has this effect: typing that key sequence from either the second frame
 > (with the wide echo area/minibuffer) or from the first frame (with the
 > normal echo area/minibuffer) creates a frame with a normal echo area/
 > minibuffer.

Can you try bisecting when this started to appear?

martin

bug#23124: Two minibuffer resize related bugs

[Eli Zaretskii]

> Date: Tue, 29 Mar 2016 17:12:56 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 23124@debbugs.gnu.org
> 
>  >> (1) Save the attached foo.el file somewhere and make its first line match
>  >>       the location where you stored it.
>  >>
>  >> (2) Start Emacs with the options -Q and -l to load foo.el.
>  >>
>  >> (3) Type C-x 5 2.
>  >>
>  >> (4) Go back to the initial frame, move to the end of the last non-empty
>  >>       line after ";; (bar)" and type C-x C-e.
>  >>
>  >> At this moment "nothing" happens here (Bug#1).  When I now switch (via
>  >> Alt TAB) to the new frame (the one created via C-x 5 2), the message
>  >> appears there.  When I now type C-p in the new frame, the minibuffer
>  >> window shrinks back but the space previously occupied by the modeline of
>  >> the window above is not redrawn, hence I get two modelines above each
>  >> other (Bug#2).
> 
> I've now traced this behavior back to this

"This behavior" being what? both the "nothing happens" part and the
"duplicate mode line" part?

> commit 9d6ec23f7d4f8fbbfdcea353c4b58e47f76a7342
> Author: Eli Zaretskii <eliz@gnu.org>
> Date:   Sat Oct 24 18:54:15 2015 +0300
> 
>      Update frame title when redisplay scrolls selected window
> 
>      * src/xdisp.c (redisplay_window): Reconsider the frame's title
>      when the mode-line of the frame's selected window needs to be
>      updated.
> 
> In fact, removing the
> 
>        x_consider_frame_title (w->frame);
> 
> call from redisplay_window fixes both bugs here.

Can you explain how the call to x_consider_frame_title causes problems
with the echo area and the mode line?  That function recomputes the
frame's title, and AFAIK does nothing more.  So I'm really confused
here.

bug#23124: Two minibuffer resize related bugs

[martin rudalics]

 >>   >> At this moment "nothing" happens here (Bug#1).  When I now switch (via
 >>   >> Alt TAB) to the new frame (the one created via C-x 5 2), the message
 >>   >> appears there.  When I now type C-p in the new frame, the minibuffer
 >>   >> window shrinks back but the space previously occupied by the modeline of
 >>   >> the window above is not redrawn, hence I get two modelines above each
 >>   >> other (Bug#2).
 >>
 >> I've now traced this behavior back to this
 >
 > "This behavior" being what? both the "nothing happens" part and the
 > "duplicate mode line" part?

Yes, both.

 >> In fact, removing the
 >>
 >>         x_consider_frame_title (w->frame);
 >>
 >> call from redisplay_window fixes both bugs here.
 >
 > Can you explain how the call to x_consider_frame_title causes problems
 > with the echo area and the mode line?

Be assured I would have done that if I had found a clue.

 > That function recomputes the
 > frame's title, and AFAIK does nothing more.  So I'm really confused
 > here.

The only explanation I have is that frame creation in some way screws up
the unwind protection logic, but how?  Naively thought "frame creation
already screwed up selected frame or window but that fact manifests
itself only now via the unwind protection logic".

martin

bug#23124: Two minibuffer resize related bugs

[Eli Zaretskii]

> Date: Tue, 29 Mar 2016 18:02:19 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 23124@debbugs.gnu.org
> 
>  >>   >> At this moment "nothing" happens here (Bug#1).  When I now switch (via
>  >>   >> Alt TAB) to the new frame (the one created via C-x 5 2), the message
>  >>   >> appears there.  When I now type C-p in the new frame, the minibuffer
>  >>   >> window shrinks back but the space previously occupied by the modeline of
>  >>   >> the window above is not redrawn, hence I get two modelines above each
>  >>   >> other (Bug#2).
>  >>
>  >> I've now traced this behavior back to this
>  >
>  > "This behavior" being what? both the "nothing happens" part and the
>  > "duplicate mode line" part?
> 
> Yes, both.
> 
>  >> In fact, removing the
>  >>
>  >>         x_consider_frame_title (w->frame);
>  >>
>  >> call from redisplay_window fixes both bugs here.
>  >
>  > Can you explain how the call to x_consider_frame_title causes problems
>  > with the echo area and the mode line?
> 
> Be assured I would have done that if I had found a clue.

I think I might have.  Does the patch below give good results?

diff --git a/src/xdisp.c b/src/xdisp.c
index d701306..bf8068b 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -17082,7 +17082,10 @@ redisplay_window (Lisp_Object window, bool just_this_one_p)
 	    ignore_mouse_drag_p = true;
 #endif
         }
+      ptrdiff_t count1 = SPECPDL_INDEX ();
+      specbind (Qinhibit_redisplay, Qt);
       x_consider_frame_title (w->frame);
+      unbind_to (count1, Qnil);
 #endif
     }
 

bug#23124: Two minibuffer resize related bugs

[martin rudalics]

 > I think I might have.

Please elaborate, shortly.

 > Does the patch below give good results?

It does; with Lucid and Windows.

Thanks, martin

bug#23124: Two minibuffer resize related bugs

[Eli Zaretskii]

> Date: Tue, 29 Mar 2016 19:20:30 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 23124@debbugs.gnu.org
> 
>  > I think I might have.
> 
> Please elaborate, shortly.

x_consider_frame_title calls Fselect_frame, which calls
resize_mini_window, which can undo the echo-area display.  The change
makes the resize_mini_window call a no-op.

>  > Does the patch below give good results?
> 
> It does; with Lucid and Windows.

Thanks, installed.

Is there something else to do wrt this bug report?

bug#23124: Two minibuffer resize related bugs

[martin rudalics]

 > x_consider_frame_title calls Fselect_frame, which calls
 > resize_mini_window, which can undo the echo-area display.  The change
 > makes the resize_mini_window call a no-op.

Darn!  I already had this in one of my logs - some 9 consecutive calls
of ‘window--resize-root-window-vertically’ in one and the same redisplay
cycle expanding and contracting the echo areas IIRC.

 > Is there something else to do wrt this bug report?

I don't think so.  If Steve's bug is not fixed now, a separate report
seems due anyway.  And if your "C-x 5 2" scenario is not already covered
anywhere else, you probably should file a separate report as well.

Thanks again for the fix, martin

bug#23124: Two minibuffer resize related bugs

[Eli Zaretskii]

> Date: Wed, 30 Mar 2016 10:38:59 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 23124@debbugs.gnu.org
> 
>  > Is there something else to do wrt this bug report?
> 
> I don't think so.

OK, closing.

> Thanks again for the fix, martin

Thanks for identifying the culprit, which made the analysis easy.

bug#23124: Two minibuffer resize related bugs

[Stephen Berman]

On Tue, 29 Mar 2016 17:13:08 +0200 martin rudalics <rudalics@gmx.at> wrote:

>>> I have no idea why C-x 5 2 should resize the echo area in the first
>>> place.  Are you sure this happened with Eli's scenario above?
>>
>> Yes; I verified it before sending my post yesterday, and again just now.
>
> I cannot reproduce the problem here.  Can you get a backtrace from where
> grow_mini_window is called?
>
>> It does, however, appear to be the case that only the first `C-x 5 2'
>> has this effect: typing that key sequence from either the second frame
>> (with the wide echo area/minibuffer) or from the first frame (with the
>> normal echo area/minibuffer) creates a frame with a normal echo area/
>> minibuffer.
>
> Can you try bisecting when this started to appear?

On Wed, 30 Mar 2016 10:38:59 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> Is there something else to do wrt this bug report?
>
> I don't think so.  If Steve's bug is not fixed now, a separate report
> seems due anyway.  

Sorry for the long delay in replying; I was away for a week and only saw
your followup mail and Eli's proposed fix last night and could not
attend to it till now.  I was hopeful that it also fixes the resizing I
observed, but I just built from the latest emacs-25 sources, which
include that fix, tried the recipe and the resizing happened again.
However, I now find that I cannot reliably reproduce it: on repeating
the recipe several times the resizing happened one or two more times but
then no more.  I also tried all previous builds I have, going back to
emacs-25.0.90, and in most cases did not get the resizing, but it did
happen a few times, but again not reproducibly (including the build I
was using when I initially posted my observation to this thread).  So I
guess it's no use trying to bisect or debug the problem, or filing a
separate bug report for it.  Too bad.

>                    And if your "C-x 5 2" scenario is not already covered
> anywhere else, you probably should file a separate report as well.

With Eli's fix I still observe "C-x 5 2" in the new frame's echo area,
irrespective of whether the resizing happens or not.

Steve Berman