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

[Dmitry Gutov]

On 21/07/2024 17:55, Eli Zaretskii wrote:
> > 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.

No problem.

> > >     . 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.

Seems so to me. You could see the way Emacs behaves without breakpoints 
at the beginning of the previous video.

> > >     . 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.

Yup, done that, see below.

> > In the former case, that will be a lot of text to sort through.
>
> Yes, but it is imperative to see all the calls.

Very good, see this longer video where I also print the backtrace every 
time the breakpoint is hit (and then sometimes scroll up to make its top 
visible). Also attached is the text log with all 12 backtraces together.

https://streamable.com/4a1vb2

The video will be up for 24 hours at this free hosting, but I can 
reupload it later as well if somebody asks.

> > > 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.

Here's hoping.

> 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.

Sounds great!

emacs-lldb-bt-3-list.txt
Description: Text document