bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 09 Apr 2012 14:07:43 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 11199@debbugs.gnu.org
> 
> Does the patch below fixes the problem?  It does not fix the root
> cause, but should work around it well enough for the release branch.
> I will install a better (but more risky) fix on the trunk.

Actually, I found a better fix that should be safe for both branch and
trunk.  Please try it, instead of the one I sent before.

> (There was nothing wrong with the end.pos values above, as long as the
> Hebrew text in the next line existed: end.pos gives the position of
> the leftmost character on display in that line, which is not
> necessarily the first character after the newline.  The problem is
> that init_to_row_end should not use row->end at all.)

Strike that last sentence, init_to_row_end is doing its job correctly.
These issues were finalized almost 2 years ago, and I succeeded to
forget all the gory details of this complexity.

Here's the patch to try:

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-03-31 19:30:53 +0000
+++ src/xdisp.c	2012-04-09 11:46:50 +0000
@@ -16602,7 +16602,15 @@ find_last_unchanged_at_beg_row (struct w
 	     continued.  */
 	  && !(MATRIX_ROW_END_CHARPOS (row) == first_changed_pos
 	       && (row->continued_p
-		   || row->exact_window_width_line_p)))
+		   || row->exact_window_width_line_p))
+	  /* If ROW->end is beyond ZV, then ROW->end is outdated and
+	     needs to be recomputed, so don't consider this row as
+	     unchanged.  This happens when the last line was
+	     bidi-reordered and was killed immediately before this
+	     redisplay cycle.  In that case, ROW->end stores the
+	     buffer position of the first visual-order character of
+	     the next row, which is now beyond ZV.  */
+	  && CHARPOS (row->end.pos) <= ZV)
 	row_found = row;
 
       /* Stop if last visible row.  */