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: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71866 <at> debbugs.gnu.org
Subject: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization
Date: Sat, 20 Jul 2024 18:46:50 +0300

On 20/07/2024 11:30, Eli Zaretskii wrote:

>> Anyway, while wrong, the behavior is not the same, so I can't be sure
>> it's the same problem that is being triggered.
> 
> 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?

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

When I have to switch to another application to handle the breakpoints 
(just typing 'c RET'), the behavior becomes different.

> Also, if the problem persists in a non-optimized build, I suggest to
> use that, since then the backtraces will be much more helpful, and
> there will be no "optimized-out" variables whose values you cannot see
> in the debugger.

Would the same backtrace that I sent, but without optimized-out 
variables, be more useful?

Previous Next

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