bug#45898: 27.1; wedged in redisplay again

[Eli Zaretskii]

> Cc: Emacs-hacker2018@jovi.net, 45898@debbugs.gnu.org
> Date: Wed, 08 Jun 2022 17:08:56 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: Emacs-hacker2018@jovi.net,  45898@debbugs.gnu.org
> > Date: Wed, 08 Jun 2022 13:47:28 +0200
> > 
> > But if we had this facility (i.e., a way to make Emacs call some
> > function after `C-g'-ing a lot during redisplay), then we can start
> > experimenting -- and users can, too.  So I think having a
> > `break-during-redisplay-function' variable that specifies something to
> > be called in these situations would allow some possible progress in this
> > area.
> 
> One problem with this is that we already have the "emergency exit"
> feature, which is triggered by 2 or more C-g's.  This only works
> reliably on TTY frames, but it's still a feature we don't want to
> lose.
> 
> The other problem is that I don't know how to do this safely.

Btw, this says "redisplay", but that's somewhat misleading: in many
cases I've seen, at least half of the time, and sometimes most of it,
is spent in the move_it_* functions, which are called both from the
display engine (to make layout decisions), and more-or-less directly
from Lisp, like via posn-at-point, vertical-motion, and scrolling
commands.  These are not "redisplay", strictly speaking, although they
reuse a lot of the display code.

So one challenge is to detect the "during redisplay" situation,
including the fact that it's "still the same redisplay cycle".

As for the C-g idea, I think a better and cleaner idea would be to use
atimers to detect signs of potentially a very long redisplay cycle,
and then do...something.  Not unlike what we already do with the
hourglass-cursor feature.

Other clever ideas are welcome.