Subject: Re: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization

From: Dmitry Gutov <[email-masked]>
Date: Sun, 21 Jul 2024 03:53:26 +0300

On 20/07/2024 19:03, Eli Zaretskii wrote:
>> Date: Sat, 20 Jul 2024 18:46:50 +0300
>> Cc: [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>>> 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 do see a bunch of such calls earlier as well, but they don't seem to
>> result in no cursor being displayed - just in it not being updated, maybe?
> 
> It depends on what was redrawn before that.

Perhaps it'll be easier to share a video. Sorry, it's a large file, so I 
just uploaded it to a free online hosting: https://streamable.com/d6775w

The first (smaller) part is me reproducing the bug, then I switch to the 
terminal emulator, enable the breakpoint and demonstrate how the 
behavior of the same command (other-frame) changes.

After the video was finished, I also repeated the same scenario, and 
saved the backtrace of the last (12th) breakpoint hit.

>>> 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?
>>
>> The scenario that I'm trying is the same that creates the original problem.
> 
> That's not what you said, or maybe I misunderstood.
> 
> But anyway, if this is the same scenario, then why are you only
> looking at what happens inside ns_draw_window_cursor?  Redrawing the
> block cursor involves displaying the character under cursor with
> special colors, and ns_draw_window_cursor is just the beginning: it
> calls other functions which actually do the job.

More breakpoints means more chances for the behavior to change. I also 
don't really know which other places to look at. Stepping through all 
the callees is both time-consuming and something that is unlikely to 
help until I manage to read all of the underlying implementation and 
start making sense of the data that's being used, to be able to notice 
when this or that variable has an odd value.

But maybe at this point some print-debugging might be more beneficial 
(since that shouldn't change the existing behavior). See the linked 
video and the attached backtrace, though.

> In addition, I don't think I understand from the debug session which
> call to ns_draw_window_cursor was done in what situation.  If they all
> were part of the single repetition of the scenario, then without fully
> functional backtraces it is very hard to understand anything that goes
> on here.  Using an unoptimized build might help, which is why I
> suggested that (unless the problem disappears in an unoptimized
> build).

Yes, I've reconfigured and rebuilt with CFLAGS="-O0 -g3". That fixed the 
backtrace printing, at least.