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

[Dmitry Gutov <dmitry@gutov.dev>]

On 21/07/2024 10:20, Eli Zaretskii wrote:
>> 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.

I can repeat the experiment, but in my testing the problem only occurs 
in (all) frames other than the first/original one, regardless of their 
positioning.

Also FWIW it doesn't matter whether the frames display the same buffer 
or different ones.

>    . 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.

>    . 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.

That's 'other-frame', bound to 'M-`'.

>    . 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.

Would you like to see all the other backtraces, or some specific ones? 
In the former case, that will be a lot of text to sort through.

> 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.

...and whether that all is a red herring, caused by our breakpoints, 
whereas the code reading to the original problem might reside somewhere 
else. ;-(

>>> 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.

Maybe I'll ask some questions later, which I know what to ask. I can 
understand some high-level things from the backtrace already, but the 
devil is in the details.