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

[Markus Triska <triska@metalevel.at>]

Eli Zaretskii <eliz@gnu.org> writes:

> 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.

In many such cases, I would like to get an expression about how far
along Emacs has already come, and also to see whether the actions I
automated contain obvious errors which would become immediately apparent
from seeing a sequence of intermediary steps which are displayed like a
movie. In addition, also in cases where I do know that everything works
correctly, I would often like to show these steps to others so that they
get an impression about what is going on internally. Seeing only a
stalled Emacs prevents a truly impressive and enjoyable presentation. In
addition, I would like to automate everything reliably in the sense that
it runs in the same way irrespective of what else is going on, such as
whether a key is accidentally pressed, the mouse is moved etc.


> 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?

In this concrete case, I looked at the documentation of `redisplay', and
it reads, at the start:

    Perform redisplay.

Since I see no redisplay, I wondered whether the documentation is in
fact correct. This is what led me to reporting this issue, in the hope
that someone cares sufficiently about Emacs to align the functionality
of redisplay with its documentation.

> 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.

Thank you a lot! If there are any questions, please let me know.

All the best,
Markus