Re: Truncating scroll runs that copy to where we copied to

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Tue, 22 Nov 2011 01:04:45 -0500, Eli Zaretskii <eliz@gnu.org> said:

> You can help if you explain in more detail what is wrong with the
> current code.  That is what I need to assess the correctness of the
> patch.  I hoped that Yamamoto-san would do that.  Failing that, I'll
> need to figure it out myself, which will take more time, and thus
> will have to wait a couple of days until I have that time to sit
> down and look into this.  I do intend to do that, make no mistake.

Actually, I told what was wrong with the current code in my first
post:

>>>>> On Sun, 20 Nov 2011 16:13:59 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I think that `scrolling_window' needs to truncate scroll runs that
> copy to where we copied to; otherwise, `assign_row (to, from)'
> assigns a previously disabled bogus row in the desired matrix when
> we have an overlap in the copy destination.

	/* Assign matrix rows.  */
	for (j = 0; j < r->nrows; ++j)
	  {
	    struct glyph_row *from, *to;
	    int to_overlapped_p;

	    to = MATRIX_ROW (current_matrix, r->desired_vpos + j);
	    from = MATRIX_ROW (desired_matrix, r->desired_vpos + j);
	    to_overlapped_p = to->overlapped_p;
	    from->redraw_fringe_bitmaps_p = from->fringe_bitmap_periodic_p;
	    assign_row (to, from);
	    to->enabled_p = 1, from->enabled_p = 0;
	    to->overlapped_p = to_overlapped_p;
	  }

If there's an overlap (I don't mean the variable to_overlapped_p) in
the copy destinations of two runs, then `from' row in the desired
matrix becomes a bogus one that had been in the current matrix after
processing the first run (because assign_row actually does swap), and
that row is disabled by `from->enabled_p = 0'.  So, when processing
the second run, the `from' row is now the previously disabled bogus
row and it is assigned to a row in the current matrix.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp