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

Previous Next

Full log

Message #32 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: Wed, 10 Jul 2024 05:46:35 +0300

On 09/07/2024 14:31, Eli Zaretskii wrote:
>> Date: Tue, 9 Jul 2024 05:37:10 +0300
>> Cc: 71866 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>>> 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.
> 
> I don't think I understand what you are trying to do.  I thought you
> needed to "switch to the Emacs window" just once: to trigger the
> situation which you want to investigate.  Once you trigger it, the
> debugger will indeed kick in, but all you need to do next is step
> through the code, so why do you care about switching to Emacs again?

Somehow, the problem manifests when I switch between frames (two frames 
in the current repro) using C-` (bound to `other-frame').

But if I Alt-Tab to a different application and then Alt-Tab back to 
Emacs, then the glyph is rendered fine - even if the "problematic" frame 
gets selected.

> If you want to trigger this situation several times, and be able to
> activate and deactivate the breakpoint at will, I suggest the
> following technique:
> 
>    . put a breakpoint in some function that is easy to invoke
>      interactively, but which otherwise is rarely called (my personal
>      favorite is Frecenter, which you can then trigger with C-l)
>    . put a breakpoint in ns_draw_window_cursor (or wherever you need),
>      but make it disabled (the GDB command is "disable N" where N is
>      the breakpoint number)
>    . when you are ready to trigger the issue, type C-l, which will
>      cause the debugger to kick in, and enable the breakpoint in
>      ns_draw_window_cursor
>    . continue Emacs, then trigger the ns_draw_window_cursor breakpoint
>      and investigate

At this point the breakpoint will start hitting as soon as I switch to 
an Emacs frame. I guess what would be ideal is a breakpoint which won't 
hit until after I switch to another frame.

>    . when you are done investigating and want to, say, set a breakpoint
>      in some other place, do that, make the breakpoint disabled again
>      and continue Emacs
>    . when ready, type C-l again, enable the disabled breakpoint, and
>      repeat the above procedure
> 
> Another, or perhaps complementary, technique is to define conditions
> for breakpoints so that they trigger only when you want.  For example,
> if you want a breakpoint to trigger only for a specific frame or
> window, find out the address of the corresponding struct window or
> struct frame (assuming there are variables of these types in the same
> scope as the breakpoint), then make the breakpoint conditioned on
> those variables having (or not having) those specific values.  The
> usual method of finding out these addresses is the first time the
> breakpoint triggers.  Then you can do:
> 
>    (gdb) print f
>      $1 = (struct frame *) 0x1234567812345600
>    (gdb) condition 3 f == 0x1234567812345600
> 
> This makes breakpoint 3 trigger only when struct frame variable f has
> the value of this frame.

So step 1 find out the address of the second frame, step 2 switch to 
first frame, step 3 enable a conditional breakpoint.

Thank you, I'll try experimenting with that.

Previous Next

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