> I don't expect to have a window that has no lines showing text.  I
 > believe we don't allow creation/resizing of windows to such a small
 > size?  If that's not guaranteed, I'm okay with adding an assertion
 > somewhere, but that would be a separate problem: we never expected
 > such a calamity even before tab-lines were added.

We did.  Try with emacs 26 loading my old test-popup-2.el (attached
once more).  Type C-x 2 and make the lower window as low as you can.
Now hit F2.  The lower window shows no text.

So we did allow windows showing no text before and I see no reason why
we should call that a calamity.  Rather, we should eliminate all
assertions that forbid zero size windows and simply not draw a cursor
when a window's body shrinks to zero pixels.  All applications I know
of tolerate such zero size "windows".

I plan a slight modification that would allow the minibuffer window to
shrink to zero lines whenever it's not used.  OTOH, zero size "normal"
windows would allow to show the minibuffer window in a frame that can
acommodate only one or two lines.

 > If we don't call set_cursor_from_row, we will not have a cursor
 > displayed where it should be, which is a display bug in and of itself.

Isn't that statement overly conservative?  Sooner or later, Emacs will
at least have to allow a mode where the region is not destroyed when a
window is scrolled, allowing the cursor to disappear from the visible
part of its buffer.

We should keep Emacs distinctive.  But being distinctive doesn't
necessarily mean to be restrictive.

 >> BTW: I would also recommend to rename mode_line_p to something like
 >> say "no_text_line_p".  Presently, people like me not used to hack the
 >> display code, might consider mode_line_p verbatim and not apply its
 >> semantics to header or tab lines.
 >
 > Sorry, but that ship sailed a long time ago.  You will have to make do
 > with the comments in dispextern.h, which document this weirdness.

Which comment?  In either case, rest assured that ordinary people will
have considerable troubles understanding code like the proposed

	  if (row->tab_line_p)
	    ++row;
	  if (row->mode_line_p)
	    ++row;

Notwithstanding my concerns, the patch fixes the bug here.

Many thanks, martin