bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38966: 27.0.60; Assertion failure in set_cursor_from_row


From: martin rudalics
Subject: bug#38966: 27.0.60; Assertion failure in set_cursor_from_row
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.  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

Attachment: test-popup-2.el
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]