8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid

8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid

[Dmitry Antipov]

To reproduce:

1) Rewind tree to 8af8355c3f72500986f6f10b62714b228d6f35ee (git checkout 8af8355c3f72500986f6f10b62714b228d6f35ee -b test)
2) Configure with ../emacs/configure --without-all --with-x-toolkit=lucid and compile
3) Run Emacs as ./src/emacs -Q --eval '(progn (menu-bar-mode 0) (tool-bar-mode 0) (scroll-bar-mode -1))'
4) Type M-x and look at the minibuffer. It remains empty, but 'M-x' should be displayed.

At 6cd2629bd1b3ce77d29ac28e29237c94a4197116, minibuffer behaves as expected.

Dmitry

Re: 8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid

[martin rudalics]

 > 1) Rewind tree to 8af8355c3f72500986f6f10b62714b228d6f35ee (git checkout 8af8355c3f72500986f6f10b62714b228d6f35ee -b test)
 > 2) Configure with ../emacs/configure --without-all --with-x-toolkit=lucid and compile
 > 3) Run Emacs as ./src/emacs -Q --eval '(progn (menu-bar-mode 0) (tool-bar-mode 0) (scroll-bar-mode -1))'
 > 4) Type M-x and look at the minibuffer. It remains empty, but 'M-x' should be displayed.
 >
 > At 6cd2629bd1b3ce77d29ac28e29237c94a4197116, minibuffer behaves as expected.

Thanks.  Here (menu-bar-mode 0) is not needed.  Same behavior on Motif
and Windows.

I'll look into this.  If you have any ideas please don't hesitate to
tell me.

martin

Re: 8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid

[Eli Zaretskii]

> Date: Tue, 06 Oct 2015 12:20:17 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > 1) Rewind tree to 8af8355c3f72500986f6f10b62714b228d6f35ee (git checkout 8af8355c3f72500986f6f10b62714b228d6f35ee -b test)
>  > 2) Configure with ../emacs/configure --without-all --with-x-toolkit=lucid and compile
>  > 3) Run Emacs as ./src/emacs -Q --eval '(progn (menu-bar-mode 0) (tool-bar-mode 0) (scroll-bar-mode -1))'
>  > 4) Type M-x and look at the minibuffer. It remains empty, but 'M-x' should be displayed.
>  >
>  > At 6cd2629bd1b3ce77d29ac28e29237c94a4197116, minibuffer behaves as expected.
> 
> Thanks.  Here (menu-bar-mode 0) is not needed.  Same behavior on Motif
> and Windows.
> 
> I'll look into this.  If you have any ideas please don't hesitate to
> tell me.

My guess is that we don't call adjust_frame_size when the toolbar and
the scroll bar are removed, so no one tells the display engine that
the dimensions changed, and so the echo-area display is produced in a
glyph row that is now beyond the frame's lower end.  This guess is
backed up by the fact that if I drag the frame's edge even one pixel,
the problem immediately goes away.

So I think we need to arrange to call adjust_frame_size from
x_set_frame_parameters, when the parameters in question affect the
frame's dimensions.

Re: 8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid

[martin rudalics]

 > My guess is that we don't call adjust_frame_size when the toolbar and
 > the scroll bar are removed, so no one tells the display engine that
 > the dimensions changed, and so the echo-area display is produced in a
 > glyph row that is now beyond the frame's lower end.  This guess is
 > backed up by the fact that if I drag the frame's edge even one pixel,
 > the problem immediately goes away.

Yes.  The minibuffer should appear on line 34 but does so on line 35,
hence it's virtually invisible.  You can't guess that from looking at
the screen - apparently everything has been drawn correctly.  The root
window and its mode line are both OK.

 > So I think we need to arrange to call adjust_frame_size from
 > x_set_frame_parameters, when the parameters in question affect the
 > frame's dimensions.

We always do that whenever setting a frame parameter can change any of
the frame's dimensions.  Here for some mysterious reason the top line of
the minibuffer is not set up correctly in resize_frame_windows.  I'm yet
too silly to find out why.

martin

Re: 8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid

[martin rudalics]

 > To reproduce:
 >
 > 1) Rewind tree to 8af8355c3f72500986f6f10b62714b228d6f35ee (git checkout 8af8355c3f72500986f6f10b62714b228d6f35ee -b test)
 > 2) Configure with ../emacs/configure --without-all --with-x-toolkit=lucid and compile
 > 3) Run Emacs as ./src/emacs -Q --eval '(progn (menu-bar-mode 0) (tool-bar-mode 0) (scroll-bar-mode -1))'
 > 4) Type M-x and look at the minibuffer. It remains empty, but 'M-x' should be displayed.
 >
 > At 6cd2629bd1b3ce77d29ac28e29237c94a4197116, minibuffer behaves as expected.

Should be fixed now, please try with latest trunk/master.

Thanks, martin

Re: 8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid

[martin rudalics]

 > We always do that whenever setting a frame parameter can change any of
 > the frame's dimensions.  Here for some mysterious reason the top line of
 > the minibuffer is not set up correctly in resize_frame_windows.  I'm yet
 > too silly to find out why.

It was a silly bug.  A more intuitive recipe to reproduce it was

(progn (split-window) (tool-bar-mode 0) (scroll-bar-mode -1))

The old code contained this logic: adjust_frame_size calls
resize_frame_windows a first time when

      (new_windows_width != old_windows_width)

and a second time when

      (new_windows_height != old_windows_height
       /* When the top margin has changed we have to recalculate the top
	 edges of all windows.  No such calculation is necessary for the
	 left edges.  */
       || WINDOW_TOP_PIXEL_EDGE (r) != FRAME_TOP_MARGIN_HEIGHT (f))

But the old resize_frame_windows code _unconditionally_ set

   r->top_line = FRAME_TOP_MARGIN (f);
   r->pixel_top = FRAME_TOP_MARGIN_HEIGHT (f);

As a consequence, the first call of resize_frame_windows (the one
assigning new widths to windows) did set the top pixel edge of the
frame's root window to the new value of the frame's top margin (the one
after removing the tool bar).  The second call of resize_frame_windows
(the one assigning the new height values) was not executed because
adjust_frame_size decided that (1) the overall height of the frame's
windows did not change (which is obvious when removing scroll bars but
also when removing the tool bar while a frame is created) and (2) the
top pixel edge of the root window already had the right value.

martin