Re: 8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid

[martin rudalics <rudalics@gmx.at>]

 > 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