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

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: 53798@debbugs.gnu.org
> Date: Sat, 05 Feb 2022 19:24:28 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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 tried to do this by using as the final form instead:
> 
>     (while t
>       (transform-line)
>       (redisplay)
>       (while (input-pending-p)
>         (read-char))
>       (sit-for 0.1))
> 
> 
> This reads characters as long as input-pending-p succeeds, in order to
> read all characters that are pending. However, I still can reproduce the
> issue.

Well, I can't.  So maybe it's macOS specific.

> > 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 can reproduce this: When I remove these settings, everything works as
> intended. This confirms that these settings are relevant to reproduce
> this issue.

then maybe it really _is_ macOS specific, and I shouldn't speak up
here anymore.

> The issue I am facing is the following: I have programmed Emacs to
> automate several tasks for me. For instance, in the example I posted,
> the task is to convert UnicodeData.txt to a collection of Prolog facts
> that can be queried and reasoned about with Scryer Prolog. This is an
> example of an actual task I am trying to solve. I noticed that when I
> start the automation, and then accidentally press a key, the program
> seems to stall instead of proceeding as intended, *even* when I take
> provisions, within the program, that aim to counteract the stall. For
> example, in the sample snippet I posted, I tried to manually enforce a
> redisplay by calling (redisplay), and still I do not see a
> redisplay. Instead, I see no display update at all for many iterations.

If you want Emacs to do something, why do you care about redisplay and
its rate?  Redisplay cannot affect what Emacs does, it just reflects
the snapshot of the state.

> > 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.
> 
> I am *trying* to force Emacs to redisplay. The issue I am facing is that
> the redisplay does *not* happen, even though I am using (redisplay).

I don't understand why you care.  Why not leave Emacs to its devices,
so it performs redisplay when it finishes whatever it is that you want
it to do?

> Does this explanation help? Please let me know if there is anything I
> can do to help reproduce this.

I think Alan or someone else who can look into this stuff on macOS
should chime in, because it sounds like its macOS specific.  I also
notice that the redisplay architecture on macOS have changed
dramatically since Emacs 27.1, so maybe the current code base no
longer behaves like what you see.