bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 10 Jul 2024 05:46:35 +0300
> Cc: 71866@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> It does get called. Unfortunately, as soon as I put a breakpoint there,
> >> any attempt to switch to the Emacs window drops into the debugger again
> >> - and I have switch back to the terminal emulator to enter 'c RET' 20
> >> times or so.
> > 
> > I don't think I understand what you are trying to do.  I thought you
> > needed to "switch to the Emacs window" just once: to trigger the
> > situation which you want to investigate.  Once you trigger it, the
> > debugger will indeed kick in, but all you need to do next is step
> > through the code, so why do you care about switching to Emacs again?
> 
> Somehow, the problem manifests when I switch between frames (two frames 
> in the current repro) using C-` (bound to `other-frame').
> 
> But if I Alt-Tab to a different application and then Alt-Tab back to 
> Emacs, then the glyph is rendered fine - even if the "problematic" frame 
> gets selected.

I thought you see the problem when you switch from another application
to Emacs, not only when you switch between two Emacs frames.  I see I
was mistaken.

> >    (gdb) print f
> >      $1 = (struct frame *) 0x1234567812345600
> >    (gdb) condition 3 f == 0x1234567812345600
> > 
> > This makes breakpoint 3 trigger only when struct frame variable f has
> > the value of this frame.
> 
> So step 1 find out the address of the second frame, step 2 switch to 
> first frame, step 3 enable a conditional breakpoint.

Yes.