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