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?