On 20/07/2024 19:03, Eli Zaretskii wrote: >> Date: Sat, 20 Jul 2024 18:46:50 +0300 >> Cc: 71866@debbugs.gnu.org >> From: Dmitry Gutov >> >>> 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.