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

[martin rudalics]

>>  > 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