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

[Eli Zaretskii]

> Date: Mon, 23 Dec 2013 21:02:24 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: jarekczek@poczta.onet.pl, 16051@debbugs.gnu.org
> 
>  > 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
    |
    +------> 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.

>  >   delta = nlines - FRAME_TOOL_BAR_LINES (f);
>  >
>  >   /* Don't resize the tool-bar to more than we have room for.  */
>  >   root_window = FRAME_ROOT_WINDOW (f);
>  >   root_height = WINDOW_TOTAL_LINES (XWINDOW (root_window));
>  >   if (root_height - delta < 1)
>  >     {
>  >       delta = root_height - 1;
>  >       nlines = FRAME_TOOL_BAR_LINES (f) + delta;
>  >     }
>  >
>  >   FRAME_TOOL_BAR_LINES (f) = nlines;
> 
> I understand its meaning and also that the subsequent call to
> resize_frame_windows is OK.  But, as stated above, the toolbar is not
> shrunk to one line.

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.

>  >> IIUC we want to pretend that the frame has the full toolbar (probably as
>  >> many rows as it has items), a one line root window and, if it's present,
>  >> a one line minibuffer window.  This should be robust enough to avoid a
>  >> crash.
>  >
>  > There's no crash anymore, at least not on Windows.  But doing what you
>  > suggest above means we will need to resize the entire frame, something
>  > we never did.
> 
> 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.  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.