GNU bug report logs - #56683
29.0.50; long lines fix doesn't work correctly when lines are truncated

Previous Next

Full log

Message #41 received at 56683 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: andreyorst <at> gmail.com, 56683 <at> debbugs.gnu.org,
 Gregory Heytings <gregory <at> heytings.org>
Subject: Re: 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

Eli Zaretskii <eliz <at> 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?

Previous Next

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