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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 21 Jul 2024 03:53:26 +0300
> Cc: 71866@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> Perhaps it'll be easier to share a video. Sorry, it's a large file, so I 
> just uploaded it to a free online hosting: https://streamable.com/d6775w
> 
> The first (smaller) part is me reproducing the bug, then I switch to the 
> terminal emulator, enable the breakpoint and demonstrate how the 
> behavior of the same command (other-frame) changes.
> 
> After the video was finished, I also repeated the same scenario, and 
> saved the backtrace of the last (12th) breakpoint hit.

Thanks.  The video shows some parts of the problem, but not enough
details.  It doesn't help that I don't know enough about the macOS GUI
system and conventions.  Here are some details that I'm missing:

  . The two frames are arranged in a way that the cursor in the
    left-most frame is not really visible when the right-most frame
    partially obscures it.  So it's hard to tell at all times what
    kind of cursor (or no cursor) is shown in that frame.  Could you
    please repeat the experiment after moving the right-most frame a
    bit to the right, so as not to obscure the cursor of the other
    frame?  IOW, I'd like to be able to see cursors in both frames
    regardless of which frame is selected/has focus.
  . 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?
  . What exactly are you doing with keyboard or mouse in the first
    part, where you quickly alternate the frames?  All I see is
    the initial mouse click inside the left-most frame, but the
    subsequent changes seemingly happen "by themselves", without any
    visible trigger.
  . The backtrace indicates that ns_draw_window_cursor is called from
    windowDidResignKey, which AFAIU is called when the focus changes.
    For some reason, display_and_set_cursor, which calls
    ns_draw_window_cursor, decided that cursor type should be
    NO_CURSOR, although gui_update_cursor was called with
    cursor_on_p=true, and the question is why?  You don't show any
    other backtraces, although in the video I clearly see them, and
    they use other values of cursor type.  In addition, I don't know
    which window passed to ns_draw_window_cursor (the 'w' argument)
    belongs to which frame, and without that, it is very hard to
    interpret the data of the debugging session, because I need to
    compare the calls with what I see in the Emacs frames.

IOW, the important question is: was the problematic display, where no
cursor is shown, caused by an incorrect call to ns_draw_window_cursor,
or was it caused by some other factor?  The data and the video you
presented does not allow to answer this questions.  Adding the missing
details I mentioned will probably help answer them.

> > 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.
> 
> More breakpoints means more chances for the behavior to change. I also 
> don't really know which other places to look at. Stepping through all 
> the callees is both time-consuming and something that is unlikely to 
> help until I manage to read all of the underlying implementation and 
> start making sense of the data that's being used, to be able to notice 
> when this or that variable has an odd value.

I can explain the overall logic of the implementation if it can help.

> But maybe at this point some print-debugging might be more beneficial 
> (since that shouldn't change the existing behavior). See the linked 
> video and the attached backtrace, though.

At this point, I'm not yet sure printf-debugging could help.  Maybe
later.

Thanks.

P.S. I've added Alan to this discussion, in the hope that he could
help with understanding what is going on here.