On Sat, Mar 22 , 2025 at 9:56 PM, Gerd Möllmann < gerd.moellmann@gmail.com > wrote:

> 
> 
> 
> 
> 
> Aaron Jensen < aaronjensen@gmail.com > writes:
> 
> 
> 
>> 
>> 
>> Right, and I agree. I'm trying to find a way to explain the difference
>> that Aaron sees with and
>> without his config. Otherwise I have no idea how to proceed with this.
>> 
>> 
> 
> 
> 
> >
> 
> 
> 
>> 
>> 
>> It's global-display-line-numbers-mode.
>> 
>> 
>> 
> 
> 
> 
> >
> 
> 
> 
>> 
>> 
>> Repro from emacs -Q:
>> 
>> 
>> 
> 
> 
> 
> >
> 
> 
> 
>> 
>> 
>> (defun foo ()
>> (Interactive)
>> (global-display-line-numbers-mode)
>> (term "/usr/bin/yes")
>> (switch-to-buffer "*scratch*"))
>> 
>> 
> 
> 
> 
> >
> 
> 
> 
>> 
>> 
>> Aaron
>> 
>> 
>> 
> 
> 
> 
> 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?

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

Thanks,

Aaron