GNU bug report logs - #38966
27.0.60; Assertion failure in set_cursor_from_row

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38966 <at> debbugs.gnu.org
Subject: bug#38966: 27.0.60; Assertion failure in set_cursor_from_row
Date: Mon, 6 Jan 2020 20:06:21 +0100

[Message part 1 (text/plain, inline)]

> 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

[test-popup-2.el (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.