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

Previous Next

Full log

View this message in rfc822 format

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

> Date: Tue, 23 Jul 2024 04:06:39 +0300
> Cc: alan <at> idiocy.org, 71866 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> > 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.

No, because ns_draw_window_cursor was called with
cursor_type=NO_CURSOR, and in that case the function returns a couple
of lines below the breakpoint without doing anything.

So I think Alan is right, and this is the effect of the macOS built-in
double-buffering of the GUI display.  But in that case there's no hope
for us to match the code being stepped through with what's on the
glass.

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

That's what I thought, in which case the mystery of NO_CURSOR still
stands.

Previous Next

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