GNU bug report logs - #71866
30.0.50; [macOS] Cursor hiding char behind it with certain theme customization

Previous Next

Full log

Message #23 received at 71866 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71866 <at> debbugs.gnu.org
Subject: Re: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with
 certain theme customization
Date: Tue, 9 Jul 2024 05:37:10 +0300

Hi Eli,

On 06/07/2024 11:56, Eli Zaretskii wrote:
>> Date: Tue, 2 Jul 2024 04:07:11 +0300
>> Cc: 71866 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.