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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 23 Jul 2024 04:06:39 +0300
> Cc: alan@idiocy.org, 71866@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > Moreover, the only event in the video where a previously-displayed
> > cursor disappears in one of the windows is the last part, where you
> > type "c" and the debugger says "Process 7616 resuming".  And that
> > happens without ns_draw_window_cursor being called!
> 
> I think that could still have happened in ns_draw_window_cursor.
> 
> We hit the breakpoint at the beginning of the function, right? So when I 
> just choose 'continue' the rest of the function executes, and the thing 
> with the cursor might happen then.

No, because ns_draw_window_cursor was called with
cursor_type=NO_CURSOR, and in that case the function returns a couple
of lines below the breakpoint without doing anything.

So I think Alan is right, and this is the effect of the macOS built-in
double-buffering of the GUI display.  But in that case there's no hope
for us to match the code being stepped through with what's on the
glass.

> > Also, what are your values of cursor-type and
> > cursor-in-non-selected-windows?
> 
> The defaults (or the default for the platform, maybe): cursor-type is t, 
> cursor-in-non-selected-windows is t.

That's what I thought, in which case the mystery of NO_CURSOR still
stands.