On Tue, Mar 18, 2025 at 6:19 AM, Eli Zaretskii wrote: > From: Gerd Möllmann Cc: Eli Zaretskii gnu.org>, alan@idiocy.org, 77039@debbugs.gnu.org Date: Tue, 18 Mar 2025 > 07:02:53 +0100 > > Aaron Jensen writes: > > Not Lisp, but: > > emacs -Q > M-x shell > yes > C-x b > > 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. > I tried to explain that I wasn't convinced that it was that, that it could have, and even likely was, a redisplay of the currently displayed buffer (which is why *it* was flickering). Unless anyone thinks that there is reason to investigate further, I'm satisfied with the answer that reading process output can cause a comparison of glyphs, which is unlikely to result in a redisplay of an unrelated buffer. If you'd like me to try the FILE/LINE logging, please let me know and I'd be happy to do it. Thanks, Aaron