bug#16051: 24.3.50; Emacs hang - resize frame manually

[martin rudalics <rudalics@gmx.at>]

 >>  > If you are right, then I'm confused: the call to
 >>  > Fmodify_frame_parameters that changes the tool-bar-lines parameter
 >>  > leads to a call to x_set_tool_bar_lines, which in turn resizes the
 >>  > tool-bar window.  And the value is certainly not always 1, I've seen
 >>  > it as large as 7.
 >>
 >> This must be the display code which takes the deviation via the frame
 >> parameter to communicate the new size to resize_frame_windows.  Not very
 >> clean IMHO.
 >
 > No, that's not what happens.  What happens is this call sequence:
 >
 >   Fmodify_frame_parameters

Who calls Fmodify_frame_parameters here?  It's redisplay_tool_bar in

       if (new_height != WINDOW_PIXEL_HEIGHT (w))
           ...
	  Fmodify_frame_parameters (frame,
				    list1 (Fcons (Qtool_bar_lines,
						  make_number (new_lines))));

discovering that the present line doesn't suffice.

 >     |
 >     +------> x_set_frame_parameters
 >                 |
 >                 +-------> x_set_tool_bar_lines
 >
 > (The last call is via the FRAME_RIF (f)->frame_parm_handlers[] array.)
 >
 >>  > Well, the old code simply left at least one screen line to the window,
 >>  > and if the tool bar asked for more than that, its request was not
 >>  > honored:
 >>
 >> This is not what I see with 24.3: With emacs -Q make the frame very
 >> narrow and shrink its height.  Here I see 3 tool-bar lines but no root
 >> or minibuffer window.
 >
 > I'm talking about what the code did, not about the effect.  FWIW,
 > Emacs 24.3 just hits an assertion when I try that:
 >
 >   xdisp.c:1053: Emacs fatal error: assertion failed: height >= 0
 >
 > I guess your Emacs 24.3 is built without --enable-checking.

Probably.  Not entirely relieving to see that the problem is not new.

 > The code above does not attempt to shrink the toolbar to one line, it
 > limits the DELTA, i.e. the additional lines the toolbar will get, to
 > the height of the frame's root window minus one line.  IOW, it shrinks
 > the rest of the root window to one line.

And this is completely wrong at this place.  I already marked the
problem when I applied my changes but forgot about it.  It's here:

/* Max tool-bar height.  Basically, this is what makes all other windows
    disappear when the frame gets too small.  Rethink this!  */

#define MAX_FRAME_TOOL_BAR_HEIGHT(f) \
   ((FRAME_LINE_HEIGHT (f) * FRAME_LINES (f)))

This means that the toolbar is allowed to grasp the whole frame, killing
everything else.

 >> No.  I meant to keep the frame size fixed at some minimum value and let
 >> the window manager do the clipping - just as it does now.
 >
 > The frame size should remain as it was -- as the user determined by
 > dragging.

But this means that we currently do change the frame size.

 > We should not change it.  The question is what value should
 > we limit the tool bar to, given those constraints, and how much space
 > should we leave to the rest of the root window of the frame.

What we do when there's no toolbar, I presume.  That is, if there's not
enough space, then kill the toolbar.

martin