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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 20 Jul 2024 18:46:50 +0300
> Cc: 71866@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > I don't really see any useful information here, except that the last
> > call tells Emacs to show the cursor using type NO_CURSOR (i.e. not to
> > display anything).
> 
> I do see a bunch of such calls earlier as well, but they don't seem to 
> result in no cursor being displayed - just in it not being updated, maybe?

It depends on what was redrawn before that.

> > I don't understand why this happens; the value is
> > returned by get_window_cursor_type called inside
> > display_and_set_cursor (which is what gui_update_window_end calls on
> > line 3941 of dispnew.c, but the backtrace doesn't even mention that).
> > 
> > But before we try to analyze this situation, shouldn't we try to stick
> > to the original issue?  Why could not you investigate what happens in
> > that case?
> 
> The scenario that I'm trying is the same that creates the original problem.

That's not what you said, or maybe I misunderstood.

But anyway, if this is the same scenario, then why are you only
looking at what happens inside ns_draw_window_cursor?  Redrawing the
block cursor involves displaying the character under cursor with
special colors, and ns_draw_window_cursor is just the beginning: it
calls other functions which actually do the job.

In addition, I don't think I understand from the debug session which
call to ns_draw_window_cursor was done in what situation.  If they all
were part of the single repetition of the scenario, then without fully
functional backtraces it is very hard to understand anything that goes
on here.  Using an unoptimized build might help, which is why I
suggested that (unless the problem disappears in an unoptimized
build).