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

[Dmitry Gutov <dmitry@gutov.dev>]

Hi Eli,

On 06/07/2024 11:56, Eli Zaretskii wrote:
>> Date: Tue, 2 Jul 2024 04:07:11 +0300
>> Cc: 71866@debbugs.gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 01/07/2024 14:36, Eli Zaretskii wrote:
>>> On other platforms, the code which draws the cursor is in draw_glyphs,
>>> called from XXX_draw_window_cursor function (where XXX is the GUI
>>> backend, in your case probably XXX = ns).  If the same is true on
>>> macOS, you could try stepping through that code.
>>
>> I can try following some more detailed instructions. I.e. I can set up a
>> breakpoint, but would there be anything to look out for when stepping
>> through the code?
> 
> For starters, put a breakpoint in ns_draw_window_cursor and see if it
> gets called in the scenario where you see the problem.

Thank you.

It does get called. Unfortunately, as soon as I put a breakpoint there, 
any attempt to switch to the Emacs window drops into the debugger again 
- and I have switch back to the terminal emulator to enter 'c RET' 20 
times or so.

So it seems difficult to go through the exact scenario where I'm 
switching between frames, where switching back to one draws the glyph 
incorrectly. Any advice with that?

> If it does get called, it should call draw_phys_cursor_glyph in this
> case (because the cursor type is FILLED_BOX_CURSOR).  If it calls that
> function, step through it.  You should see there that it calls
> draw_glyphs to draw the single character under the cursor.  The actual
> drawing happens here:
> 
>    /* Draw all strings.  */
>    for (s = head; s; s = s->next)
>      FRAME_RIF (f)->draw_glyph_string (s);
> 
> where the draw_glyph_string method is a function in nsterm.m,
> ns_draw_glyph_string.  AFAICT, it should draw a character with the
> foreground taken from the frame's background color and background
> color taken from the cursor color.
> 
> Something in this chain of calls doesn't happen in the scenario which
> shows the problem.
> 
>> BTW, this happens only right after I switch frames. Things start looking
>> right again if I simply move point.
> 
> Then step through the code after switching frames.