bug#62573: 29.0.60; Cursor color not being inverted in emacs-29

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: luangruo@yahoo.com,  62573@debbugs.gnu.org,  abdo.haji.ali@gmail.com
> Date: Sun, 02 Apr 2023 13:01:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Daniel Martín <mardani29@yahoo.es>
> >> Cc: Al Haji-Ali <abdo.haji.ali@gmail.com>,  62573@debbugs.gnu.org,
> >>  luangruo@yahoo.com
> >> Date: Sat, 01 Apr 2023 21:56:33 +0200
> >> 
> >> This bug is a regression caused by
> >> 07715630ad9df9cb681cbadecbaf73fc9c698061.  (Adding Po Lu to the CC.)
> >> 
> >> >From what I see, the font display refactor removed this code from
> >> src/nsterm.m:
> >> 
> >> -  face = FACE_FROM_ID_OR_NULL (f, phys_cursor_glyph->face_id);
> >> -  if (face && NS_FACE_BACKGROUND (face)
> >> -      == ns_index_color (FRAME_CURSOR_COLOR (f), f))
> >> -    {
> >> -      [ns_lookup_indexed_color (NS_FACE_FOREGROUND (face), f) set];
> >> -      hollow_color = FRAME_CURSOR_COLOR (f);
> >> -    }
> >> -  else
> >> 
> >> which seems to be responsible for the cursor color change when the
> >> background face color is the same as the cursor color.  I can't find
> >> that logic in the current code, so I think we miss it from the
> >> refactoring.
> >> 
> >> I've solved the bug by replicating that logic in the appropriate places,
> >> nsterm.m and macfont.m:
> >
> > This regression should be fixed on the release branch, but the patch
> > you propose is quite large.  Can't we simply reinstate the removed
> > code, and apply the changes you propose only on master?
> >
> 
> That's the first thing I tried, but it didn't fix the problem.  More
> code changes would be needed because, since
> 07715630ad9df9cb681cbadecbaf73fc9c698061, the responsibility of drawing
> the cursor now resides in the macOS font driver (macfont.m).

OK, thanks, understood.