Subject: bug#75931: 31.0.50; mouse-face and pointer properties make pointer change back and forth

From: Mauro Aranda <[email-masked]>
Date: Thu, 30 Jan 2025 06:57:32 -0300

Eli Zaretskii <[email-masked]> writes:

 >> Date: Wed, 29 Jan 2025 20:30:05 -0300
 >> Cc: [email-masked]
 >> From: Mauro Aranda <[email-masked]>
 >>
 >> On 29/1/25 16:11, Eli Zaretskii wrote:
 >>  >> Date: Wed, 29 Jan 2025 15:27:24 -0300
 >>  >> From: Mauro Aranda <[email-masked]>
 >>  >> Cc: Eli Zaretskii <[email-masked]>
 >>  >>
 >>  >> I bisected it down to this commit:
 >>  >>
 >>  >> commit 64f9fdc812bb2e1f533ae294355d33396985e469
 >>  >> Author: Eli Zaretskii <[email-masked]>
 >>  >> Date:   Thu Oct 14 11:57:07 2021 +0300
 >>  >>
 >>  >>      Fix display of cursor in mouse-highlighted face with ':box'
 >>  >>
 >>  >>      * src/xdisp.c (erase_phys_cursor, show_mouse_face): Adjust
 >>  >>      phys_cursor.x as needed if the cursor is inside 
mouse-highlight.
 >>  >>      (get_cursor_offset_for_mouse_face): New function.
 >>  >>      * src/dispnew.c (gui_update_window_end): Set
 >>  >>      'mouse_face_overwritten_p' if the cursor is in mouse-face, to
 >>  >>      trigger more thorough redisplay of the cursor.
 >>  >>      (Bug#50660)
 >>  >
 >>  > Thanks, but it would still be good to know which code changes the
 >>  > mouse pointer to hand.  In the above patch, the only part that could
 >>  > perhaps cause that is the first hunk, in dispnew.c, but I don't 
see an
 >>  > immediate connection, especially since the answer is probably
 >>  > somewhere in X-specific code (xterm.c etc.).
 >>
 >> I'll keep digging.
 >
 > Thanks.  Can you verify that reverting the first hunk of that
 > changeset (2 added lines in dispnew.c:gui_update_window_end) solves
 > the problem?  If not, then I'm afraid I'm on the wrong track and don't
 > understand how the rest of that changeset could cause this regression.

Reverting that hunk on master doesn't solve it, but has a minor effect:
Previously, the back and forth change between hand and arrow happens
when showing the cursor and when hidding it.  If I revert the hunk, it
only happens when hidding it, so it solves half the problem.

Now, if I go back to your commit, then commenting out that change in
dispnew.c does indeed solve the problem.  But the next commit to xdisp.c
is this:
commit 2028df7826bb2c2909b2aaeba47282ca70c514e3
Author: Po Lu <[email-masked]>
Date:   Thu Oct 14 18:38:26 2021 +0800

     Fix minor issues with text display when cursor is in mouse face

      * src/xdisp.c (get_cursor_offset_for_mouse_face): Don't calculate
     offsets for the glyph the cursor is on, and move some logic to
     get_glyph_pixel_width_delta_for_mouse_face.
     (fill_composite_glyph_string)
     (fill_gstring_glyph_string)
     (fill_glyphless_glyph_string)
     (fill_glyph_string)
     (fill_image_glyph_string)
     (fill_xwidget_glyph_string)
     (fill_stretch_glyph_string): Set s->face to mouse face whenever
     appropriate.
     (get_glyph_pixel_width_delta_for_mouse_face): New function.
     (set_glyph_string_background_width): Update background width and
     s->width to take into account differing :box properties of the mouse
     face, when producing strings for the cursor.
     (erase_phys_cursor): Redraw mouse face when erasing a cursor on top of
     the mouse face.
      * src/xterm.c (x_set_mouse_face_gc): Stop setting s->face when under
     mouse face because redisplay now does that for us.
      * src/w32term.c (w32_set_mouse_face_gc): Likewise.

And that commit makes the issue reappear.  And as I said, now reverting
the change in dispnew.c only solves half the problem.

Perhaps it is the call to show_mouse_face that was added to
erase_phys_cursor.

 > (I wouldn't be asking these questions if I could reproduce the problem
 > on my machine, but I cannot, unfortunately.)

That's OK.  I just hope I can help you figure it out, I doubt I could do
it on my own.