[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: |
Eli Zaretskii |
Subject: |
bug#38966: 27.0.60; Assertion failure in set_cursor_from_row |
Date: |
Mon, 06 Jan 2020 21:50:51 +0200 |
> 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.
- 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, 2020/01/06
- bug#38966: 27.0.60; Assertion failure in set_cursor_from_row,
Eli Zaretskii <=
- 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