Re: 8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid

[martin rudalics <rudalics@gmx.at>]

 > 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