bug#45737: 27.1.50; Assertion failure in window_box_height

[martin rudalics <rudalics@gmx.at>]

 > So the frame will resize as result dragging by mouse, but the
 > mini-window will not be visible?

Right.  With our gtk size hints, for example, we set

#define FRAME_TEXT_LINES_TO_PIXEL_HEIGHT(f, lines) \
   ((lines) * FRAME_LINE_HEIGHT (f)		   \
    + FRAME_TOP_MARGIN_HEIGHT (f)		   \
    + FRAME_SCROLL_BAR_HEIGHT (f)		   \
    + 2 * FRAME_INTERNAL_BORDER_WIDTH (f))

   base_height = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, 1)
     + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f);

so we pretend that tab, menu and scroll bar, internal border and one
text line remain visible.  With the earlier recipe I get one text line
for the topmost normal window(s).  With

(progn
   (ruler-mode)
   (tab-line-mode)
   (horizontal-scroll-bar-mode)
   (split-window (split-window) nil t)
   (split-window)
   (split-window (split-window nil nil t) nil t))

the smallest frame shows the normal windows with a tab line and a ruler,
apparently stealing the space from the scroll bar.  The mini window
never shows up in practice.

 > If that is the effect, then I'm okay with installing this on emacs-27,
 > but I wonder whether we could do better on master, so as to ensure
 > that at least one screen line of the mini-window is still visible?

That would be better indeed.  But I suppose this would require to
implement zero-height windows, something you didn't like when we
discussed it about a year ago.

Alternatively, we (maybe) could set our size hints in a way that all
windows can be shown but maybe people wouldn't like it and on Windows
there's no way to do that without frames snapping back.

 > Btw, is this issue new in Emacs 27, or did it exist before?

New because tab lines didn't exist before Emacs 27.  And I couldn't
reproduce it with the ruler - maybe because it never wanted to write
something into the echo area.

martin