bug#45898: 27.1; wedged in redisplay again

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sat, 25 Jun 2022 11:49:42 +0200
> Cc: 45898@debbugs.gnu.org
> 
> Well... update_display_code_iteration_ticks also makes me twitch because I think of the tick/signal business not part of "display".  What I have in my head is regexp -> ticks, and iterator -> ticks, where "ticks" would be replaced with some suitable name. I think regexp should also be interrupted with long lines, when we match a line that is too long.  Or not?
> 
> Or maybe "ticks" is already a good enough name?  We could then simply have update_ticks and good.  Or eticks to not confuse it with time ticks, if that ever happens.

You mean, just update_ticks?  That's too general, IMO.  I'd like
people to have an idea what that does when they just see the call.

But I'm not good with names.

> >> (BTW, the call to update the tick in regexp can lead to a GC when the error is signaled, in the same way as
> >> in bug 56108 with maybe_quit.  So we might need that, too.)
> > 
> > Yes, it could cause GC, but I'm not sure what you mean by "we might
> > need that".  What is "that" here?  
> 
> I meant a fix for that bug.  

Ah, okay.  That will get installed soon, I'm just waiting for Stefan
to comment if he has comments.

> >> /* True while some display-engine code is working on layout of some
> >>   window.
> > 
> > The reason for that kludge is the urge to avoid signaling an error
> > when regexp or syntax.c is called in the context that is not related
> > to any display code whatsoever.  Since these functions don't know
> > whether they are invoked by some code in Iterator or by Lisp, they
> > will count the ticks regardless, and I don't want them to signal an
> > error if they happen to count too many ticks.
> 
> You mean a case, where small numbers of ticks sum up by calling these Lisp functions often enough?

Actually, I meant something even simpler: a Lisp program that calls,
say, regexp search repeatedly, to accumulate enough ticks that would
signal an error, thus aborting that Lisp program.

> Apart from features I don't know, I don't see any fundamental problem with your approach.

Great, thanks.