bug#9229: 24.0.50; Bidi problem with `cursor' property

bug#9229: 24.0.50; Bidi problem with `cursor' property

[Johan Bockgård]

The `cursor' property does not work properly on overlays when
bidi-display-reordering is t and the overlay string is line wrapped.

   emacs -Q

Eval

    (let ((o (make-overlay (point-max) (point-max)))
          (s (make-string (+ 5 (window-width)) ?-)))
      (put-text-property 0 1 'cursor t s)
      (overlay-put o 'after-string s)
      (goto-char (point-max)))

The cursor is expected to be displayed before the overlay, but is
displayed after it.

(This bug makes icomplete-mode very confusing to use.)

bug#9229: 24.0.50; Bidi problem with `cursor' property

[Eli Zaretskii]

> From: Johan Bockgård <bojohan@gnu.org>
> Date: Wed, 03 Aug 2011 16:29:52 +0200
> 
> 
>     (let ((o (make-overlay (point-max) (point-max)))
>           (s (make-string (+ 5 (window-width)) ?-)))
>       (put-text-property 0 1 'cursor t s)
>       (overlay-put o 'after-string s)
>       (goto-char (point-max)))
> 
> The cursor is expected to be displayed before the overlay, but is
> displayed after it.
> 
> (This bug makes icomplete-mode very confusing to use.)

Thanks, I will get to this soon.  Sorry for the inconvenience.

bug#9229: 24.0.50; Bidi problem with `cursor' property

[Eli Zaretskii]

> Date: Wed, 03 Aug 2011 19:19:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9229@debbugs.gnu.org
> 
> > From: Johan Bockgård <bojohan@gnu.org>
> > Date: Wed, 03 Aug 2011 16:29:52 +0200
> > 
> > 
> >     (let ((o (make-overlay (point-max) (point-max)))
> >           (s (make-string (+ 5 (window-width)) ?-)))
> >       (put-text-property 0 1 'cursor t s)
> >       (overlay-put o 'after-string s)
> >       (goto-char (point-max)))
> > 
> > The cursor is expected to be displayed before the overlay, but is
> > displayed after it.
> > 
> > (This bug makes icomplete-mode very confusing to use.)

Does the patch below give good results?  If it solves this particular
problem, please try it in your regular use for a day or two, and see
if there are any adverse effects.  If you don't spot any trouble, I
will install this on the trunk.

Thanks.

Here's the patch to try:

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2011-08-03 05:24:30 +0000
+++ src/xdisp.c	2011-08-03 19:04:49 +0000
@@ -13706,14 +13706,15 @@ set_cursor_from_row (struct window *w, s
       w->cursor.vpos >= 0
       /* that candidate is not the row we are processing */
       && MATRIX_ROW (matrix, w->cursor.vpos) != row
-      /* the row we are processing is part of a continued line */
-      && (row->continued_p || MATRIX_ROW_CONTINUATION_LINE_P (row))
       /* Make sure cursor.vpos specifies a row whose start and end
 	 charpos occlude point.  This is because some callers of this
 	 function leave cursor.vpos at the row where the cursor was
 	 displayed during the last redisplay cycle.  */
       && MATRIX_ROW_START_CHARPOS (MATRIX_ROW (matrix, w->cursor.vpos)) <= pt_old
-      && pt_old < MATRIX_ROW_END_CHARPOS (MATRIX_ROW (matrix, w->cursor.vpos)))
+      && (pt_old < MATRIX_ROW_END_CHARPOS (MATRIX_ROW (matrix, w->cursor.vpos))
+	  /* the entire line is from display string */
+	  || (pt_old == MATRIX_ROW_START_CHARPOS (MATRIX_ROW (matrix, w->cursor.vpos))
+	      && pt_old == MATRIX_ROW_END_CHARPOS (MATRIX_ROW (matrix, w->cursor.vpos)))))
     {
       struct glyph *g1 =
 	MATRIX_ROW_GLYPH_START (matrix, w->cursor.vpos) + w->cursor.hpos;
@@ -13722,15 +13723,20 @@ set_cursor_from_row (struct window *w, s
       if (!(row->reversed_p ? glyph > glyphs_end : glyph < glyphs_end))
 	return 0;
       /* Keep the candidate whose buffer position is the closest to
-	 point.  */
+	 point or has the `cursor' property.  */
       if (/* previous candidate is a glyph in TEXT_AREA of that row */
 	  w->cursor.hpos >= 0
 	  && w->cursor.hpos < MATRIX_ROW_USED (matrix, w->cursor.vpos)
-	  && BUFFERP (g1->object)
-	  && (g1->charpos == pt_old /* an exact match always wins */
-	      || (BUFFERP (glyph->object)
-		  && eabs (g1->charpos - pt_old)
-		   < eabs (glyph->charpos - pt_old))))
+	  && ((BUFFERP (g1->object)
+	       && (g1->charpos == pt_old /* an exact match always wins */
+		   || (BUFFERP (glyph->object)
+		       && eabs (g1->charpos - pt_old)
+		       < eabs (glyph->charpos - pt_old))))
+	      /* previous candidate is a glyph from a string that has
+		 a non-nil `cursor' property */
+	      || (STRINGP (g1->object)
+		  && !NILP (Fget_char_property (make_number (g1->charpos),
+						Qcursor, g1->object)))))
 	return 0;
       /* If this candidate gives an exact match, use that.  */
       if (!(BUFFERP (glyph->object) && glyph->charpos == pt_old)

bug#9229: 24.0.50; Bidi problem with `cursor' property

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 03 Aug 2011 19:19:45 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 9229@debbugs.gnu.org
>> 
>> > From: Johan Bockgård <bojohan@gnu.org>
>> > Date: Wed, 03 Aug 2011 16:29:52 +0200
>> > 
>> > 
>> >     (let ((o (make-overlay (point-max) (point-max)))
>> >           (s (make-string (+ 5 (window-width)) ?-)))
>> >       (put-text-property 0 1 'cursor t s)
>> >       (overlay-put o 'after-string s)
>> >       (goto-char (point-max)))
>> > 
>> > The cursor is expected to be displayed before the overlay, but is
>> > displayed after it.
>> > 
>> > (This bug makes icomplete-mode very confusing to use.)
>
> Does the patch below give good results?  If it solves this particular
> problem, please try it in your regular use for a day or two, and see
> if there are any adverse effects.  If you don't spot any trouble, I
> will install this on the trunk.

Apparently, the patch only tries to fix the case where "the entire line
is from display string", which doesn't solve the icomplete problem:

emacs -Q

M-x icomplete-mode RET

M-x a

bug#9229: 24.0.50; Bidi problem with `cursor' property

[Eli Zaretskii]

> From: Johan Bockgård <bojohan@gnu.org>
> Cc: 9229@debbugs.gnu.org
> Date: Wed, 03 Aug 2011 22:03:51 +0200
> 
> Apparently, the patch only tries to fix the case where "the entire line
> is from display string", which doesn't solve the icomplete problem:
> 
> emacs -Q
> 
> M-x icomplete-mode RET
> 
> M-x a

What about this one?  (Apply it after "bzr revert".)

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2011-08-03 05:24:30 +0000
+++ src/xdisp.c	2011-08-03 20:33:08 +0000
@@ -13706,14 +13706,12 @@ set_cursor_from_row (struct window *w, s
       w->cursor.vpos >= 0
       /* that candidate is not the row we are processing */
       && MATRIX_ROW (matrix, w->cursor.vpos) != row
-      /* the row we are processing is part of a continued line */
-      && (row->continued_p || MATRIX_ROW_CONTINUATION_LINE_P (row))
       /* Make sure cursor.vpos specifies a row whose start and end
 	 charpos occlude point.  This is because some callers of this
 	 function leave cursor.vpos at the row where the cursor was
 	 displayed during the last redisplay cycle.  */
       && MATRIX_ROW_START_CHARPOS (MATRIX_ROW (matrix, w->cursor.vpos)) <= pt_old
-      && pt_old < MATRIX_ROW_END_CHARPOS (MATRIX_ROW (matrix, w->cursor.vpos)))
+      && pt_old <= MATRIX_ROW_END_CHARPOS (MATRIX_ROW (matrix, w->cursor.vpos)))
     {
       struct glyph *g1 =
 	MATRIX_ROW_GLYPH_START (matrix, w->cursor.vpos) + w->cursor.hpos;
@@ -13722,15 +13720,20 @@ set_cursor_from_row (struct window *w, s
       if (!(row->reversed_p ? glyph > glyphs_end : glyph < glyphs_end))
 	return 0;
       /* Keep the candidate whose buffer position is the closest to
-	 point.  */
+	 point or has the `cursor' property.  */
       if (/* previous candidate is a glyph in TEXT_AREA of that row */
 	  w->cursor.hpos >= 0
 	  && w->cursor.hpos < MATRIX_ROW_USED (matrix, w->cursor.vpos)
-	  && BUFFERP (g1->object)
-	  && (g1->charpos == pt_old /* an exact match always wins */
-	      || (BUFFERP (glyph->object)
-		  && eabs (g1->charpos - pt_old)
-		   < eabs (glyph->charpos - pt_old))))
+	  && ((BUFFERP (g1->object)
+	       && (g1->charpos == pt_old /* an exact match always wins */
+		   || (BUFFERP (glyph->object)
+		       && eabs (g1->charpos - pt_old)
+		       < eabs (glyph->charpos - pt_old))))
+	      /* previous candidate is a glyph from a string that has
+		 a non-nil `cursor' property */
+	      || (STRINGP (g1->object)
+		  && !NILP (Fget_char_property (make_number (g1->charpos),
+						Qcursor, g1->object)))))
 	return 0;
       /* If this candidate gives an exact match, use that.  */
       if (!(BUFFERP (glyph->object) && glyph->charpos == pt_old)

bug#9229: 24.0.50; Bidi problem with `cursor' property

[Eli Zaretskii]

> Date: Wed, 03 Aug 2011 23:41:49 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9229@debbugs.gnu.org
> 
> > From: Johan Bockgård <bojohan@gnu.org>
> > Cc: 9229@debbugs.gnu.org
> > Date: Wed, 03 Aug 2011 22:03:51 +0200
> > 
> > Apparently, the patch only tries to fix the case where "the entire line
> > is from display string", which doesn't solve the icomplete problem:
> > 
> > emacs -Q
> > 
> > M-x icomplete-mode RET
> > 
> > M-x a
> 
> What about this one?  (Apply it after "bzr revert".)

Any experience with this patch, positive or otherwise?

TIA

bug#9229: 24.0.50; Bidi problem with `cursor' property

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

> Any experience with this patch, positive or otherwise?

It works so far. Thanks.

bug#9229: 24.0.50; Bidi problem with `cursor' property

[Eli Zaretskii]

> From: Johan Bockgård <bojohan@gnu.org>
> Cc: 9229@debbugs.gnu.org
> Date: Thu, 04 Aug 2011 18:45:51 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Any experience with this patch, positive or otherwise?
> 
> It works so far. Thanks.

Committed as revision 105406 on the trunk.  Thanks.