bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Third
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]