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

Previous Next

Package: emacs;

Reported by: Andrey Listopadov <andreyorst <at> gmail.com>

Date: Thu, 21 Jul 2022 19:00:02 UTC

Severity: normal

Found in version 29.0.50

Full log


View this message in rfc822 format

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: 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?




This bug report was last modified 2 years and 326 days ago.

Previous Next


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