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: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71866 <at> debbugs.gnu.org
Subject: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization
Date: Fri, 19 Jul 2024 04:57:12 +0300

[Message part 1 (text/plain, inline)]

On 10/07/2024 14:58, Eli Zaretskii wrote:
>> Date: Wed, 10 Jul 2024 05:46:35 +0300
>> Cc: 71866 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>>>> 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.
> 
> I thought you see the problem when you switch from another application
> to Emacs, not only when you switch between two Emacs frames.  I see I
> was mistaken.
> 
>>>     (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.
> 
> Yes.

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.

[emacs-lldb-log.txt (text/plain, attachment)]

Previous Next

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