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

[Dmitry Gutov <dmitry@gutov.dev>]

On 22/07/2024 17:45, Eli Zaretskii wrote:

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

Yes, I started this second video with focus in the terminal emulator (on 
the right - you could see that I was typing there some into text for the 
person watching). So that seems fine, no bug there.

Then I switch to the first Emacs frame, and its chrome becomes colored.

We spend most of the video in the terminal emulator as well (which is 
necessary for me to handle the breakpoints), so overall that's expected. 
You could notice somewhere in the middle of the video that after I 
handle a bunch of breakpoints the focus finally shifts to Emacs, second 
frame. But more breakpoints hit, so I have to switch back to the 
terminal emulator until the end of the recording.

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

That sounds interesting but a bit too complex for me to address, for now.

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

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

Thanks for the instructions, I think I'll do that tomorrow.

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