bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay

[Eli Zaretskii <eliz@gnu.org>]

> From: Markus Triska <triska@metalevel.at>
> Cc: 53798@debbugs.gnu.org
> Date: Sat, 05 Feb 2022 18:29:08 +0100
> 
>     $ emacs -Q redisplay.el -f eval-buffer
> 
> then the forms will open UnicodeData.txt which ships with Emacs (please
> adjust the path if necessary), and then will apply a certain
> transformation on each line of the file.
> 
> You will see that each line is changed as intended, and we see each
> change immediately as it takes effect. However, unexpectedly, when
> several keys are pressed quickly in a row, the program apparently
> stalls, and no longer performs any actions, for several seconds.

If you press several keys, you need to call read-char that number of
time, or empty the input queue in some other way.  Otherwise, you
still have input available after calling read-char, like in the
original recipe, because you pressed more than one key.

I'm not on macOS, so I commented out the part of the recipe that deals
with interprogram-cut-function.  When I run the result, I see no
abnormal behavior, even if I press several keys.

I'm not sure I understand what you are trying to establish with these
recipes.  What is the actual issue you are trying to solve, and why
the call to redisplay/sit-for and pressing keys are part of that?

> I found that the settings of interprogram-cut-function and
> save-interprogram-paste-before-kill are relevant to reproduce this
> issue. Could it be that how these settings are treated internally may
> interfere with how Emacs redisplays things, and whether it stalls?

What do you mean by "how Emacs redisplays things"?  In these recipes,
you actually force Emacs to do redisplay, both by calling 'redisplay'
and by calling 'sit-for', instead of letting it do it "naturally".  So
I wonder where all this is going, and why.