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
[Message part 1 (text/plain, inline)]
On 20/07/2024 19:03, Eli Zaretskii wrote:
>> Date: Sat, 20 Jul 2024 18:46:50 +0300
>> Cc: 71866 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>>> 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?
>
> It depends on what was redrawn before that.
Perhaps it'll be easier to share a video. Sorry, it's a large file, so I
just uploaded it to a free online hosting: https://streamable.com/d6775w
The first (smaller) part is me reproducing the bug, then I switch to the
terminal emulator, enable the breakpoint and demonstrate how the
behavior of the same command (other-frame) changes.
After the video was finished, I also repeated the same scenario, and
saved the backtrace of the last (12th) breakpoint hit.
>>> 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.
>
> That's not what you said, or maybe I misunderstood.
>
> 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.
But maybe at this point some print-debugging might be more beneficial
(since that shouldn't change the existing behavior). See the linked
video and the attached backtrace, though.
> In addition, I don't think I understand from the debug session which
> call to ns_draw_window_cursor was done in what situation. If they all
> were part of the single repetition of the scenario, then without fully
> functional backtraces it is very hard to understand anything that goes
> on here. Using an unoptimized build might help, which is why I
> suggested that (unless the problem disappears in an unoptimized
> build).
Yes, I've reconfigured and rebuilt with CFLAGS="-O0 -g3". That fixed the
backtrace printing, at least.
[emacs-lldb-bt-2.txt (text/plain, attachment)]
This bug report was last modified 326 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.