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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 23 Jul 2024 14:17:20 +0300

> Date: Tue, 23 Jul 2024 04:06:39 +0300
> Cc: [email-masked], [email-masked]
> From: Dmitry Gutov <[email-masked]>
> 
> > 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.