Re: 8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid

[Eli Zaretskii]

> Date: Tue, 06 Oct 2015 12:20:17 +0200
> From: martin rudalics <address@hidden>
> 
>  > 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.