Subject: bug#77039: 31.0.50; Flickering on macOS

From: Gerd Möllmann <[email-masked]>
Date: Sun, 23 Mar 2025 06:41:10 +0100

"Aaron Jensen" <[email-masked]> writes:

>  Thanks! I think I see now what's going on. 
>
>  redisplay_internal has this (line numbers may differ): 
>
>  xdisp.c: 
>  17368 && (NILP (Vdisplay_line_numbers) 17369 || EQ (Vdisplay_line_numbers, Qvisual)) 
>
>  This means that certain redisplay optimizations that make redisplay particularly "cheap" are not
>  tried, depending on line number display. 
>
>  Instead the more expensive redisplay methods are used that consider whole windows or parts of them
>  and so on. Or, in other words, line number display can make redisplay less of a nop. 
>
>  So, with line numbers, hidden buffer with process -> wait_reading_process_output ->
>  redisplay_internal -> update_window (or similar) -> ... -> row_equal_p -> the equal macros
>
> My vterm buffers do not have line numbers, so it sounds like it's
> considering the line number status of the currently visible window,
> does that sound right?

Yes, it's the value in current_buffer. Don't see ATM where that is set,
but it's normally the buffer of the selected window. Maybe that's
implicitly the case if consider_all_windows is false. 

>
> And it looks like there's a FIXME comment right above it:
>
> ```
>    /* FIXME: The following condition is only needed when
> significant parts of the buffer are hidden (e.g., under
> hs-minor-mode), but there doesn't seem to be a simple way of
> detecting that, so we always disable the one-line redisplay
> optimizations whenever display-line-numbers-mode is turned on
> in the buffer.  */

Yeah, I've seen that, but I couldn't figure out what circumstance
prevents using the optimizations in this case, specifically when line
numbers are displayed. An enigma :-).