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

[Eli Zaretskii]

> Date: Tue, 9 Jul 2024 05:37:10 +0300
> Cc: 71866@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > For starters, put a breakpoint in ns_draw_window_cursor and see if it
> > gets called in the scenario where you see the problem.
> 
> Thank you.
> 
> 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?

If you want to trigger this situation several times, and be able to
activate and deactivate the breakpoint at will, I suggest the
following technique:

  . put a breakpoint in some function that is easy to invoke
    interactively, but which otherwise is rarely called (my personal
    favorite is Frecenter, which you can then trigger with C-l)
  . put a breakpoint in ns_draw_window_cursor (or wherever you need),
    but make it disabled (the GDB command is "disable N" where N is
    the breakpoint number)
  . when you are ready to trigger the issue, type C-l, which will
    cause the debugger to kick in, and enable the breakpoint in
    ns_draw_window_cursor
  . continue Emacs, then trigger the ns_draw_window_cursor breakpoint
    and investigate
  . when you are done investigating and want to, say, set a breakpoint
    in some other place, do that, make the breakpoint disabled again
    and continue Emacs
  . when ready, type C-l again, enable the disabled breakpoint, and
    repeat the above procedure

Another, or perhaps complementary, technique is to define conditions
for breakpoints so that they trigger only when you want.  For example,
if you want a breakpoint to trigger only for a specific frame or
window, find out the address of the corresponding struct window or
struct frame (assuming there are variables of these types in the same
scope as the breakpoint), then make the breakpoint conditioned on
those variables having (or not having) those specific values.  The
usual method of finding out these addresses is the first time the
breakpoint triggers.  Then you can do:

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

HTH