bug#38966: 27.0.60; Assertion failure in set_cursor_from_row

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 38966@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 6 Jan 2020 20:06:21 +0100
> 
>  > 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.

OK, let me rephrase: _I_ didn't, okay?  IOW, the display code doesn't,
and AFAIR never did.

(For some reason I seem to make people angry today, and you seem to be
one of them.  Apologies -- I don't know for what.)

> 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.

Why is such a window useful?  I thought we had a minimum window height
beyond which we didn't allow to resize windows.  Isn't that true
anymore?

> 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.

All I'm saying is that making the display code prepared to deal with
such windows might take more changes, and this would be a separate
issue, suitable for master, not for the release branch.  OK?

>  > 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.

That's not the same situation.  If point is not in the window, it's OK
not to display the cursor.  But I'm talking about a situation where
point _is_ in the window.

>  > 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?

This one:

  /* True means row is a mode or header/tab-line.  */
  bool_bf mode_line_p : 1;

> 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;

I added comments explaining what's going on.

> Notwithstanding my concerns, the patch fixes the bug here.

Thanks, pushed to the emacs-27 branch, and closing the bug.