bug#45737: 27.1.50; Assertion failure in window_box_height

[martin rudalics]

> 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