From: Gerd Möllmann <gerd.moellmann@gmail.com> Cc: Eli Zaretskii <eliz@gnu.org>, alan@idiocy.org, 77039@debbugs.gnu.org Date: Tue, 18 Mar 2025 07:02:53 +0100

Aaron Jensen <aaronjensen@gmail.com> writes:

Not Lisp, but:

emacs -Q
M-x shell
yes<enter>
C-x b<enter>

This will open a shell in a background buffer that is rapidly printing to STDOUT (and displaying in the shell buffer) then switch to the scratch buffer. If you add logging to the matrix comparisons you will see a rapid uptick. I don't know if this has to do with the external process connection with Emacs.

To be clear, I don't know if this is actually an issue given that the matrix comparison is likely preventing the redisplay.

Aaron

When I configure with --enable-checking=glyphs, and run, in emacs -Q, GUI version the function

(defun foo ()
(interactive)
(trace-redisplay 1)
(term "/usr/bin/yes")
(switch-to-buffer "*scratch*"))

I see traces of the form

redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
...

The 12 means the call is from wait_reading_process_output, which reads the output from /usr/bin/yes in this case.

So, that explains where the redisplay comes from. Since there are no further redisplay actions shown in the trace output, I think that redisplay is more or less a nop in these cases. Didn't try without the fix that I pushed.

Yes, redisplay should be a nop, since the buffer which is modified is not displayed.

But Aaron seems to say we keep comparing the glyph matrices of the window which is not show, something that should not happen, because we don't call update_frame on frames that are not visible.