bug#72230: 29.4; Cursor Disappears with Hebrew Text

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[hermann sorgel]

[-- Attachment #1: Type: text/plain, Size: 4641 bytes --]

I'm encountering an issue with cursor behavior in Emacs, and I'm hoping
someone can help me resolve it.

When the cursor hovers over Hebrew text, it becomes invisible. Here are a
few facts I've observed:
- This only occurs with the cursor type set to 'bar'.
- The "box" and other cursor types work without issues.
- The "bar" cursor becomes visible if I make its size huge, like '(bar .
10).
- There's a similar, but slightly different issue with Arabic text.

The issue was reproduced with Emacs 29.3 for Mac and emacs-plus 29.4, on
macOS Sonoma 14.5 (23F79). Changing font and bidi settings haven't affected
the issue. Neither has --no-init-file.

Short video with demonstration
<https://e.pcloud.link/publink/show?code=XZIDjgZ3QLO9BNemLm4rGJp1Venlhq0PeI7>

Text file from video
<https://gist.github.com/hermannsorgel/a2a7de12dab858bb17da35b822721702>

Please let me know if I'm missing something.

In GNU Emacs 29.4 (build 1, aarch64-apple-darwin23.5.0, NS
 appkit-2487.60 Version 14.5 (Build 23F79)) of 2024-07-21 built on
 Sorgel-MBP
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.5

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
 --infodir=/opt/homebrew/Cellar/emacs-plus@29/29.4/share/info/emacs
 --prefix=/opt/homebrew/Cellar/emacs-plus@29/29.4 --with-xml2
 --with-gnutls --without-compress-install --without-dbus
 --without-imagemagick --with-modules --with-rsvg --with-ns
 --disable-ns-self-contained 'CFLAGS=-Os -w -pipe
 -mmacosx-version-min=14
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -O2
 -DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT'
 'CPPFLAGS=-I/opt/homebrew/opt/icu4c/include
 -I/opt/homebrew/opt/sqlite/include -I/opt/homebrew/opt/readline/include
 -isystem/opt/homebrew/include -F/opt/homebrew/Frameworks
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk'
 'LDFLAGS=-L/opt/homebrew/opt/icu4c/lib -L/opt/homebrew/opt/sqlite/lib
 -L/opt/homebrew/opt/readline/lib -L/opt/homebrew/lib
 -F/opt/homebrew/Frameworks -Wl,-headerpad_max_install_names
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS
PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER
XIM ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
thingatpt vc-git diff-mode easy-mmode vc-dispatcher cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 43275 6299)
 (symbols 48 5649 0)
 (strings 32 15396 2057)
 (string-bytes 1 443058)
 (vectors 16 11570)
 (vector-slots 8 175067 6803)
 (floats 8 23 53)
 (intervals 56 298 0)
 (buffers 984 12))

[-- Attachment #2: Type: text/html, Size: 5275 bytes --]

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Eli Zaretskii]

> From: hermann sorgel <hermannsorgel@gmail.com>
> Date: Sun, 21 Jul 2024 17:20:50 +0300
> 
> I'm encountering an issue with cursor behavior in Emacs, and I'm hoping someone can help me resolve it.
> 
> When the cursor hovers over Hebrew text, it becomes invisible. Here are a few facts I've observed:
> - This only occurs with the cursor type set to 'bar'.
> - The "box" and other cursor types work without issues.
> - The "bar" cursor becomes visible if I make its size huge, like '(bar . 10).
> - There's a similar, but slightly different issue with Arabic text.
> 
> The issue was reproduced with Emacs 29.3 for Mac and emacs-plus 29.4, on macOS Sonoma 14.5 (23F79).
> Changing font and bidi settings haven't affected the issue. Neither has --no-init-file.

Thanks.  I cannot reproduce this on my system, but I'm not on macOS.
Maybe this is specific to macOS?  Can a macOS user please try
reproducing this?

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Eli Zaretskii]

> Cc: 72230@debbugs.gnu.org
> Date: Sun, 21 Jul 2024 18:46:58 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Thanks.  I cannot reproduce this on my system, but I'm not on macOS.
> Maybe this is specific to macOS?  Can a macOS user please try
> reproducing this?

And I think I see the problem.  This fragment of nsterm.m:

    case BAR_CURSOR:
      s = r;
      /* If the character under cursor is R2L, draw the bar cursor
         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;

is incorrect: it should use the value of the cursor_width argument,
not s.size.width.  Can someone who is capable of building Emacs on
macOS please try copying more closely the code from xterm.c or
w32term.c that draws the bar cursor, and see if that solves the
problem?

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[hermann sorgel]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

Thank you, Eli!

Sadly, I'm not actually into coding, but I'm able to run make. So, the only
thing I've changed was:

s.origin.x += cursor_glyph->pixel_width - *cursor_width*;

Such a build kind of works, but does not fix the described behavior.

Also, with the help of redditors, I've found that Mitsuharu's fork of 29.1
does not have this issue. Hope this will help us find the root of the
problem.

On Sun, Jul 21, 2024 at 7:01 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: 72230@debbugs.gnu.org
> > Date: Sun, 21 Jul 2024 18:46:58 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> >
> > Thanks.  I cannot reproduce this on my system, but I'm not on macOS.
> > Maybe this is specific to macOS?  Can a macOS user please try
> > reproducing this?
>
> And I think I see the problem.  This fragment of nsterm.m:
>
>     case BAR_CURSOR:
>       s = r;
>       /* If the character under cursor is R2L, draw the bar cursor
>          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;
>
> is incorrect: it should use the value of the cursor_width argument,
> not s.size.width.  Can someone who is capable of building Emacs on
> macOS please try copying more closely the code from xterm.c or
> w32term.c that draws the bar cursor, and see if that solves the
> problem?
>

[-- Attachment #2: Type: text/html, Size: 2019 bytes --]

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[hermann sorgel]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

Here is the same code
<https://bitbucket.org/mituharu/emacs-mac/src/master/src/nsterm.m#lines-3119>
 with s.size.width in the working fork. It does not look that anything has
changed in 29.4.

On Sun, Jul 21, 2024 at 7:01 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: 72230@debbugs.gnu.org
> > Date: Sun, 21 Jul 2024 18:46:58 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> >
> > Thanks.  I cannot reproduce this on my system, but I'm not on macOS.
> > Maybe this is specific to macOS?  Can a macOS user please try
> > reproducing this?
>
> And I think I see the problem.  This fragment of nsterm.m:
>
>     case BAR_CURSOR:
>       s = r;
>       /* If the character under cursor is R2L, draw the bar cursor
>          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;
>
> is incorrect: it should use the value of the cursor_width argument,
> not s.size.width.  Can someone who is capable of building Emacs on
> macOS please try copying more closely the code from xterm.c or
> w32term.c that draws the bar cursor, and see if that solves the
> problem?
>

[-- Attachment #2: Type: text/html, Size: 2978 bytes --]

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Eli Zaretskii]

> From: hermann sorgel <hermannsorgel@gmail.com>
> Date: Sun, 21 Jul 2024 20:31:54 +0300
> Cc: 72230@debbugs.gnu.org
> 
> Here is the same code  with s.size.width in the working fork. It does not look that anything has changed in
> 29.4.

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.

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Stefan Kangas]

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?

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;

       NSRectFill (s);
       [ctx restoreGraphicsState];

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Gerd Möllmann]

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?
>
> 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;
>
>        NSRectFill (s);
>        [ctx restoreGraphicsState];

A clipping path set with NSRectClip is permanent, and the only way to
get rid it is to restore the graphics state. This seems to work:

modified   src/nsterm.m
@@ -3130,6 +3130,8 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
       [ctx restoreGraphicsState];
       break;
     case BAR_CURSOR:
+      [ctx restoreGraphicsState];
+      [ctx saveGraphicsState];
       s = r;
       /* If the character under cursor is R2L, draw the bar cursor
          on the right of its glyph, rather than on the left.  */
@@ -3137,6 +3139,10 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
       if ((cursor_glyph->resolved_level & 1) != 0)
         s.origin.x += cursor_glyph->pixel_width - s.size.width;
 
+      /* Get rid of the clipping set previously. */
+      [ctx restoreGraphicsState];
+      [ctx saveGraphicsState];
+      NSRectClip (s);
       NSRectFill (s);
       [ctx restoreGraphicsState];
       break;

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Gerd Möllmann]

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?
>
> 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;
>
>        NSRectFill (s);
>        [ctx restoreGraphicsState];

Erm, once is enough :-)

1 file changed, 4 insertions(+)
src/nsterm.m | 4 ++++

modified   src/nsterm.m
@@ -3137,6 +3137,10 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
       if ((cursor_glyph->resolved_level & 1) != 0)
         s.origin.x += cursor_glyph->pixel_width - s.size.width;
 
+      /* Get rid of the clipping set previously. */
+      [ctx restoreGraphicsState];
+      [ctx saveGraphicsState];
+      NSRectClip (s);
       NSRectFill (s);
       [ctx restoreGraphicsState];
       break;

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Stefan Kangas]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> 1 file changed, 4 insertions(+)
> src/nsterm.m | 4 ++++
>
> modified   src/nsterm.m
> @@ -3137,6 +3137,10 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
>        if ((cursor_glyph->resolved_level & 1) != 0)
>          s.origin.x += cursor_glyph->pixel_width - s.size.width;
>
> +      /* Get rid of the clipping set previously. */
> +      [ctx restoreGraphicsState];
> +      [ctx saveGraphicsState];
> +      NSRectClip (s);
>        NSRectFill (s);
>        [ctx restoreGraphicsState];
>        break;
>

This fixes the bug for me.

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[hermann sorgel]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

Yes, thank you so much. This works for me too.


On Sun, Jul 21, 2024 at 10:26 PM Stefan Kangas <stefankangas@gmail.com>
wrote:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> > 1 file changed, 4 insertions(+)
> > src/nsterm.m | 4 ++++
> >
> > modified   src/nsterm.m
> > @@ -3137,6 +3137,10 @@ Note that CURSOR_WIDTH is meaningful only for
> (h)bar cursors.
> >        if ((cursor_glyph->resolved_level & 1) != 0)
> >          s.origin.x += cursor_glyph->pixel_width - s.size.width;
> >
> > +      /* Get rid of the clipping set previously. */
> > +      [ctx restoreGraphicsState];
> > +      [ctx saveGraphicsState];
> > +      NSRectClip (s);
> >        NSRectFill (s);
> >        [ctx restoreGraphicsState];
> >        break;
> >
>
> This fixes the bug for me.
>

[-- Attachment #2: Type: text/html, Size: 1308 bytes --]

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> 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.

I propose the following as a fix. This computes the right rectangle to
draw before that rectangle is set via NSClipRect.

1 file changed, 8 insertions(+), 12 deletions(-)
src/nsterm.m | 20 ++++++++------------

modified   src/nsterm.m
@@ -3026,7 +3026,7 @@ External call (RIF): draw cursor.
      Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
    -------------------------------------------------------------------------- */
 {
-  NSRect r, s;
+  NSRect r;
   int fx, fy, h, cursor_height;
   struct frame *f = WINDOW_XFRAME (w);
   struct glyph *phys_cursor_glyph;
@@ -3076,6 +3076,12 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
       /* The bar cursor should never be wider than the glyph.  */
       if (cursor_width < w->phys_cursor_width)
         w->phys_cursor_width = cursor_width;
+
+      /* If the character under cursor is R2L, draw the bar cursor
+         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)
+        fx += cursor_glyph->pixel_width - w->phys_cursor_width;
     }
   /* If we have an HBAR, "cursor_width" MAY specify height.  */
   else if (cursor_type == HBAR_CURSOR)
@@ -3126,18 +3132,8 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
       [ctx restoreGraphicsState];
       break;
     case HBAR_CURSOR:
-      NSRectFill (r);
-      [ctx restoreGraphicsState];
-      break;
     case BAR_CURSOR:
-      s = r;
-      /* If the character under cursor is R2L, draw the bar cursor
-         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;
-
-      NSRectFill (s);
+      NSRectFill (r);
       [ctx restoreGraphicsState];
       break;
     }

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> I propose the following as a fix. This computes the right rectangle to
> draw before that rectangle is set via NSClipRect.

I've pushed this to emacs-30. Closing.

bug#72230: 29.4; Cursor Disappears with Hebrew Text

[Stefan Kangas]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> I've pushed this to emacs-30. Closing.

Thanks.