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

[martin rudalics <rudalics@gmx.at>]

 >>  > 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.
 >
 > I think we are miscommunicating, because we certainly don't change the
 > frame size; the user does.

Tha user only asks us to change it.  And the point I wanted to make here
is that instead of changing it we could refuse to change it, either by

(1) setting the according wm hints, or by

(2) issuing a re-resize request to the wm, or by

(3) simply not processing the new frame size and let the wm do the
     clipping.

Now (1) seems difficult because people can change height and width at
the same time and with a wrapping toolbar we hardly can specify the
proper hints here (essentially we would have to be able to pass the
minimum size of the Emacs window to the wm).  (2) is not nice although
we do something similar already IIRC.

So my preference for this is (3).  Which would just imply that the size
of an Emacs frame does not correspond to what the user sees.

 >>  > 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.
 >
 > That's too drastic I think.  We are perfectly capable of displaying
 > the tool bar truncated to the part that can be rendered.  If the user
 > doesn't like that, she can always turn off the tool bar manually.
 > After all, it's the user who caused this.

It's not a question of what we can display.  The problem is that our
internal understanding of the geometry of a frame is broken when the
toolbar gets a greater height than the containing frame.

martin