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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 21 Jul 2024 16:50:18 +0300
> Cc: 71866@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >    . The two frames are arranged in a way that the cursor in the
> >      left-most frame is not really visible when the right-most frame
> >      partially obscures it.  So it's hard to tell at all times what
> >      kind of cursor (or no cursor) is shown in that frame.  Could you
> >      please repeat the experiment after moving the right-most frame a
> >      bit to the right, so as not to obscure the cursor of the other
> >      frame?  IOW, I'd like to be able to see cursors in both frames
> >      regardless of which frame is selected/has focus.
> 
> I can repeat the experiment, but in my testing the problem only occurs 
> in (all) frames other than the first/original one, regardless of their 
> positioning.

I believe you.  But I want to see both cursors, because they are
usually redrawn in tandem.

> Also FWIW it doesn't matter whether the frames display the same buffer 
> or different ones.

Yes, I know.

> >    . Sometimes an Emacs frame shows its window as selected (judging by
> >      the way the mode line is displayed), but the 3 colored circles at
> >      the top left corner of the frame are shown in gray.  What does
> >      this mean, in Emacs terms, and how is that different from the
> >      situation where both the mode line is shown as active and the
> >      circles are shown in red/yellow/green colors?
> 
> It seems to me a consequence of our having a breakpoint inside a 
> function that updates how the frame looks (which includes its contents, 
> the "selected" status and etc) - when I switch the focus away manually 
> to a different program in the middle of that (to handle the breakpoint), 
> probably that created a de-synchronization that never happens in other 
> circumstances.

If you are sure that this happens only when Emacs is stopped at a
breakpoint, this aspect of the issue can be disregarded.

> >    . What exactly are you doing with keyboard or mouse in the first
> >      part, where you quickly alternate the frames?  All I see is
> >      the initial mouse click inside the left-most frame, but the
> >      subsequent changes seemingly happen "by themselves", without any
> >      visible trigger.
> 
> That's 'other-frame', bound to 'M-`'.

OK.

> >    . The backtrace indicates that ns_draw_window_cursor is called from
> >      windowDidResignKey, which AFAIU is called when the focus changes.
> >      For some reason, display_and_set_cursor, which calls
> >      ns_draw_window_cursor, decided that cursor type should be
> >      NO_CURSOR, although gui_update_cursor was called with
> >      cursor_on_p=true, and the question is why?  You don't show any
> >      other backtraces, although in the video I clearly see them, and
> >      they use other values of cursor type.  In addition, I don't know
> >      which window passed to ns_draw_window_cursor (the 'w' argument)
> >      belongs to which frame, and without that, it is very hard to
> >      interpret the data of the debugging session, because I need to
> >      compare the calls with what I see in the Emacs frames.
> 
> Would you like to see all the other backtraces, or some specific ones? 

All of the backtraces from all the calls produced by a single M-`
press.  It is best to have only the backtraces that happen when the
problem with the cursor is visible, if you can easily arrange for
that.

> In the former case, that will be a lot of text to sort through.

Yes, but it is imperative to see all the calls.

> > IOW, the important question is: was the problematic display, where no
> > cursor is shown, caused by an incorrect call to ns_draw_window_cursor,
> > or was it caused by some other factor?  The data and the video you
> > presented does not allow to answer this questions.  Adding the missing
> > details I mentioned will probably help answer them.
> 
> ...and whether that all is a red herring, caused by our breakpoints, 
> whereas the code reading to the original problem might reside somewhere 
> else. ;-(

Could be, but in general ns_draw_window_cursor is AFAIK the only way
of redrawing the cursor, so I think we are on a good track here.

> >>> 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.
> > 
> > I can explain the overall logic of the implementation if it can help.
> 
> Maybe I'll ask some questions later, which I know what to ask. I can 
> understand some high-level things from the backtrace already, but the 
> devil is in the details.

Eventually, if and when we find the call which causes this incomplete
redraw, you will need to step through the code and see what happens
there.  When we get there, I will try to explain the main ideas of the
code.

Thanks.