[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
test-popup-2.el
Description: Text document
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, martin rudalics, 2020/01/06
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, Eli Zaretskii, 2020/01/06
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row,
martin rudalics <=
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, Eli Zaretskii, 2020/01/06
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, martin rudalics, 2020/01/07
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, Eli Zaretskii, 2020/01/07
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, martin rudalics, 2020/01/07
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, Eli Zaretskii, 2020/01/07
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, martin rudalics, 2020/01/07
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, Eli Zaretskii, 2020/01/07
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, martin rudalics, 2020/01/07
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row, Eli Zaretskii, 2020/01/07