[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are
From: |
Gerd Möllmann |
Subject: |
bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated |
Date: |
Fri, 22 Jul 2022 09:28:26 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) |
Eli Zaretskii <eliz@gnu.org> writes:
> I think we should take look at this fragment from hscroll_window_tree:
>
> /* Move iterator to pt starting at cursor_row->start in
> a line with infinite width. */
> init_to_row_start (&it, w, cursor_row);
> if (hscl)
> it.first_visible_x = window_hscroll_limited (w, it.f)
> * FRAME_COLUMN_WIDTH (it.f);
> it.last_visible_x = DISP_INFINITY;
> move_it_in_display_line_to (&it, pt, -1, MOVE_TO_POS);
> /* If the line ends in an overlay string with a newline,
> we might infloop, because displaying the window will
> want to put the cursor after the overlay, i.e. at X
> coordinate of zero on the next screen line. So we
> use the buffer position prior to the overlay string
> instead. */
> if (it.method == GET_FROM_STRING && pt > 1)
> {
> init_to_row_start (&it, w, cursor_row);
> if (hscl)
> it.first_visible_x = (window_hscroll_limited (w, it.f)
> * FRAME_COLUMN_WIDTH (it.f));
> move_it_in_display_line_to (&it, pt - 1, -1, MOVE_TO_POS);
> }
>
> Specifically, init_to_row_start can potentially start from a very far
> away buffer position, especially in buffers with a single long line,
I'm not sure. Cursor_row comes from here:
if (w->cursor.vpos < bottom_row - w->desired_matrix->rows)
cursor_row = MATRIX_ROW (w->desired_matrix, w->cursor.vpos);
else
cursor_row = bottom_row - 1;
if (!cursor_row->enabled_p)
{
bottom_row = MATRIX_BOTTOM_TEXT_ROW (w->current_matrix, w);
if (w->cursor.vpos < bottom_row - w->current_matrix->rows)
cursor_row = MATRIX_ROW (w->current_matrix, w->cursor.vpos);
else
cursor_row = bottom_row - 1;
}
In my own words, either cursor_row has just been produced in the
desired_matrix, or it has been produced previously, and is now part of
the current matrix.
Doesn't that mean it was already subject to the iterator narrowing?
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, (continued)
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Gerd Möllmann, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Gerd Möllmann, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/22
bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Andrey Listopadov, 2022/07/21
bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated, Eli Zaretskii, 2022/07/22
- bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated,
Gerd Möllmann <=