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: 71866 <at> debbugs.gnu.org
Subject: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization
Date: Sat, 20 Jul 2024 11:30:06 +0300

> Date: Fri, 19 Jul 2024 04:57:12 +0300
> Cc: 71866 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> Okay, I have tried that, and the results might or might not be useful.
> 
> Similarly to the case of switching from another application, when I have 
> to switch to another application to handle the breakpoints (just typing 
> 'c RET'), the behavior is different.
> 
> BUT the last call to ns_draw_window_cursor (out of 14) before the 
> control is returned results in the cursor getting hidden (in the new 
> selected Emacs frame only). Unlike the problem I described, the 
> character under the cursor stays drawn, but the cursor rectangle goes 
> away (and that happens after the last breakpoint hit, before that the 
> text and the cursor look correctly - hollow cursor around the character).
> 
> I'm attaching the last debugging log - maybe the backtrace can be 
> useful? - but note that the backtrace printing is halfway broken as well 
> - it freezes and I have to press ^C a bunch of times to see something.
> 
> Anyway, while wrong, the behavior is not the same, so I can't be sure 
> it's the same problem that is being triggered.

I don't really see any useful information here, except that the last
call tells Emacs to show the cursor using type NO_CURSOR (i.e. not to
display anything).  I don't understand why this happens; the value is
returned by get_window_cursor_type called inside
display_and_set_cursor (which is what gui_update_window_end calls on
line 3941 of dispnew.c, but the backtrace doesn't even mention that).

But before we try to analyze this situation, shouldn't we try to stick
to the original issue?  Why could not you investigate what happens in
that case?

Also, if the problem persists in a non-optimized build, I suggest to
use that, since then the backtraces will be much more helpful, and
there will be no "optimized-out" variables whose values you cannot see
in the debugger.

Previous Next

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