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: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 71866 <at> debbugs.gnu.org
Subject: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization
Date: Mon, 22 Jul 2024 16:27:30 +0100

On Mon, Jul 22, 2024 at 05:45:44PM +0300, Eli Zaretskii wrote:
> 
> Thanks.  There's a disturbing discrepancy between what the debugger
> says about the calls to ns_draw_window_cursor and what I see on
> display.  For example, there are only 2 events where one of the two
> Emacs frames begins showing a filled-block cursor (from some other
> cursor display): at step "1" and step "3".  But the backtraces you
> collected tell a different story: the only calls with
> FILLED_BOX_CURSOR are at steps "1" and "7".  At step "3", the debugger
> claims we called ns_draw_window_cursor with NO_CURSOR, whereas the
> video clearly shows that the cursor is drawn as a filled block!  This
> issue alone already makes all this quite mysterious and hard to
> interpret.
> 
> Moreover, the only event in the video where a previously-displayed
> cursor disappears in one of the windows is the last part, where you
> type "c" and the debugger says "Process 7616 resuming".  And that
> happens without ns_draw_window_cursor being called!
> 
> So I think there's some factor at work here that we are not
> considering.  Perhaps it's the macOS window-system or something.

Hi Eli,

The macOS display system is inherently double buffered, so there's no
way to draw directly to the screen. This means any action taken won't
be displayed on the screen until the NS run loop has run at least
once. That occurs in the ns_select and ns_read_socket functions.

> > > 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.
> 
> I'm no longer so sure about the above assertion, sadly.

AFAIK it's the only way of *drawing* the cursor, but it's certainly
possible that something else is *clearing* that space and not
redrawing the cursor. Unfortunately I've no idea what that might be.

I had a bug open myself about a very similar problem, possibly the
same problem, but I closed it years ago because it just disappeared
and nobody else had ever reported anything similar. I was never able
to get to the bottom of it.
-- 
Alan Third

Previous Next

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