GNU bug report logs -
#71866
30.0.50; [macOS] Cursor hiding char behind it with certain theme customization
Previous Next
Full log
Message #17 received at 71866 <at> debbugs.gnu.org (full text, mbox):
> 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.
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.
This bug report was last modified 326 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.