bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> So maybe the problem is elsewhere.  One thing is almost certain: it's
>> a problem specific to the macOS build of Emacs.  People who can debug
>> on that platform are encouraged to suggest insights and changes.
>
> This seems to have something to with the clipping path, and is fixed
> here by the below patch. I don't think it's suitable for installing
> though.
>
> Po Lu, since you added the below NSRectClip call, do you have any
> thoughts here?

Yes, this will cause the overhangs of a cursor glyph to overwrite its
surroundings.  There is certain to be some other factor that has not
been accounted for, while mindlessly removing clipping operations is not
the solution.

> diff --git a/src/nsterm.m b/src/nsterm.m
> index 794630de1c1..54b15bc851d 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -3102,7 +3102,7 @@ Note that CURSOR_WIDTH is meaningful only for
> (h)bar cursors.
>  #ifdef NS_IMPL_GNUSTEP
>    GSRectClipList (ctx, &r, 1);
>  #else
> -  NSRectClip (r);
> +  // NSRectClip (r);
>  #endif
>
>    [FRAME_CURSOR_COLOR (f) set];
> @@ -3135,7 +3135,7 @@ Note that CURSOR_WIDTH is meaningful only for
> (h)bar cursors.
>           on the right of its glyph, rather than on the left.  */
>        cursor_glyph = get_phys_cursor_glyph (w);
>        if ((cursor_glyph->resolved_level & 1) != 0)
> -        s.origin.x += cursor_glyph->pixel_width - s.size.width;
> +        s.origin.x += cursor_glyph->pixel_width - cursor_width;

I don't recollect what `s' is supposed to represent.