> We redisplay when we get back to the main loop and there's no input

> pending. 

Where is the main loop? Could you please tell me the source code file and line number related to "getting back to the main loop"? I'm interested in the Emacs source code. Thank you.



On 9/4/24 00:06, Eli Zaretskii wrote:
Date: Tue, 03 Sep 2024 15:57:05 +0000
From: Pip Cet <pipcet@protonmail.com>
Cc: execvy@gmail.com, emacs-devel@gnu.org

"Eli Zaretskii" <eliz@gnu.org> writes:

And I don't feel any pauses with the igc branch, either.
I'm not sure key repeat is a particularly good test of GC
responsiveness; it appears to be heavily influenced by non-GC factors,
and when holding C-n, redisplay stops at some point and only catches up
when the key is released.

If I set the keyboard repeat rate to 255 using 'xset', which appears to
be the maximum supported, an MPS Emacs running my production session
(some 200 buffers) ends up exhibiting this behavior when holding C-n, so
only the first, non-repeated command is displayed properly.  A
newly-launched MPS Emacs does fine with xdisp.c in fundamental mode, but
in C mode it ends up scrolling for a bit, presumably until font-lock
does its work, then not scrolling until 'n' is released again.
I see none of this, but my auto-repeat rate is about 30/sec.

It would be nice to change this behavior to force some redisplay even
when Emacs can't keep up with keypresses, but I don't think this is an
MPS issue at this point.
For me, the MPS build is much snappier scrolling through xdisp.c (in C
mode) than the "normal" build.

Is it true that we only redisplay once all key presses have been
handled?
We redisplay when we get back to the main loop and there's no input
pending.  Depending on the input rate and the time it takes to process
each key, it could go either way.