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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 22 Jul 2024 02:58:33 +0300
> Cc: alan@idiocy.org, 71866@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >>>     . Sometimes an Emacs frame shows its window as selected (judging by
> >>>       the way the mode line is displayed), but the 3 colored circles at
> >>>       the top left corner of the frame are shown in gray.  What does
> >>>       this mean, in Emacs terms, and how is that different from the
> >>>       situation where both the mode line is shown as active and the
> >>>       circles are shown in red/yellow/green colors?
> >>
> >> It seems to me a consequence of our having a breakpoint inside a
> >> function that updates how the frame looks (which includes its contents,
> >> the "selected" status and etc) - when I switch the focus away manually
> >> to a different program in the middle of that (to handle the breakpoint),
> >> probably that created a de-synchronization that never happens in other
> >> circumstances.
> > 
> > If you are sure that this happens only when Emacs is stopped at a
> > breakpoint, this aspect of the issue can be disregarded.
> 
> Seems so to me. You could see the way Emacs behaves without breakpoints 
> at the beginning of the previous video.

But note that both at the beginning of this new video and at its end,
where the debugger says "resuming" (which means Emacs is running), the
3 circles of both Emacs frames are gray.  So I guess (a) this does
happen when Emacs runs, and (b) it probably means focus is in some
other window, not in any of the Emacs frames.

> > All of the backtraces from all the calls produced by a single M-`
> > press.  It is best to have only the backtraces that happen when the
> > problem with the cursor is visible, if you can easily arrange for
> > that.
> 
> Yup, done that, see below.

Thanks.  There's a disturbing discrepancy between what the debugger
says about the calls to ns_draw_window_cursor and what I see on
display.  For example, there are only 2 events where one of the two
Emacs frames begins showing a filled-block cursor (from some other
cursor display): at step "1" and step "3".  But the backtraces you
collected tell a different story: the only calls with
FILLED_BOX_CURSOR are at steps "1" and "7".  At step "3", the debugger
claims we called ns_draw_window_cursor with NO_CURSOR, whereas the
video clearly shows that the cursor is drawn as a filled block!  This
issue alone already makes all this quite mysterious and hard to
interpret.

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!

So I think there's some factor at work here that we are not
considering.  Perhaps it's the macOS window-system or something.

I also don't understand the calls where cursor_type=NO_CURSOR,
on_p=true, and active_p=false.  I would expect to see
HOLLOW_BOX_CURSOR there, because these are the calls where we display
the cursor in a non-selected window.  Could you step inside
get_window_cursor_type and see how this happens?  To arrange for that,
get to the step before the one where the breakpoint in
ns_draw_window_cursor will break with the above combination of
arguments (for example, get to step "3" in your session), then add a
breakpoint in display_and_set_cursor, trigger the next cursor display
by typing "continue", then step through display_and_set_cursor and
into get_window_cursor_type, and see why we end up deciding to display
NO_CURSOR in that case.

Also, what are your values of cursor-type and
cursor-in-non-selected-windows?

> >> ...and whether that all is a red herring, caused by our breakpoints,
> >> whereas the code reading to the original problem might reside somewhere
> >> else. ;-(
> > 
> > Could be, but in general ns_draw_window_cursor is AFAIK the only way
> > of redrawing the cursor, so I think we are on a good track here.
> 
> Here's hoping.

I'm no longer so sure about the above assertion, sadly.

Thanks.