bug#45898: 27.1; wedged in redisplay again

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sat, 25 Jun 2022 06:54:19 +0200
> Cc: 45898@debbugs.gnu.org
> 
> I think it helps me in the following when I briefly describe the model of 
> Emacs’ internals I have in my head. 
> That way, I can write about things in terms in which I think.  So, let me 
> try.  When I think of Emacs' design, I
> think of functions and categories they belong to.  Categories in the sense of 
> animal, dog, human, plant.   A
> bit like modules, but not quite, but if it’s helpful, just think of modules 
> instead. 
> 
> The categories I'd like to use here, are lisp, redisplay, iterator, update, 
> regexp.   I leave the rest out. Here is
> what I group under these categories:

That's clear, thanks.

> One of the first things that came to my mind is a new category "time fuse" 
> (in German Zeitzünder),
> something counting ticks, and detonating (signaling) at some point.  I admit 
> that I find the names you used
> with redisplay in them confusing.  Especially in the regexp code and so.

That's mainly to keep the names from getting too long to be useful.  I
could have used something like update_display_code_iteration_ticks,
but it looked to me that "redisplay" is a good way of saying "display
code" shorter.

> Functionality-wise, Iterator now signals an error that redisplay catches. 

Yes, that's the main idea.  But note that in some cases Iterator is
called directly from Lisp, not from Redisplay, in which case the error
is caught by the command loop (not sure where that is in your
taxonomy? is that also Lisp?), not by Redisplay.  Case in point: C-n.

> The error is signaled when a global tick counter exceeds a max value.  Each 
> movement of an iterator
> increments the global tick counter.  The counter is global because you want 
> to sum up all the ticks that
> occur between a given start point where the tick counter is set to 0, and the 
> point where the ticks exceed the
> maximum, regardless of iterator -> lisp -> iterator nesting.
> 
> The global tick counter is also incremented from regexp.  I think font-lock 
> plays a role here.  One scenario is
> redisplay or lisp -> iterator, iterator needs font-lock to run (-> lisp), 
> font-lock matches a regexp (lisp ->
> regexp), and we get stuck on a long line.  Likewise with other stuff, like 
> syntax.

Right.  But I want to explain why I count ticks in regexp, in
syntax.c, and in some places in bidi.c.  The reason is that a single
call to set_iterator_to_next, which basically counts as one tick, can
sometimes result in prolonged operations.  So some ticks are "more
equal" than others, and I looked for a way of expressing that.  What
you see in those other places is the result of that: it makes
iteration steps that trigger prolonged examination of buffer text to
count as more than one tick.

> (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?  Did you mean we should count ticks
inside GC as well?  If so, we'd need to have some way of preventing a
signal when the tick count reaches the threshold, because we cannot
signal an error inside GC.

> Maybe we could disable the calls cheaply when max-ticks is 0?  I mean, 
> something that inlines
> 
> if (max_ticks > 0)
>           update_ticks(...)

Yes, maybe.

> The meaning of display_working_on_window_p is not clear to me.  I see what 
> setting it does in the end, but I
> can't tell what this means:
> 
> /* 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.

> Do you want me to take a deeper look at specific places?

As you wish.  I just wanted a second opinion on the overall design,
and my main worry besides that is whether there are situations where
this simple mechanism could cause trouble.  E.g., Lars already
uncovered one such situation, see

  https://lists.gnu.org/archive/html/emacs-diffs/2022-06/msg00761.html

(I will redirect that to here, as emacs-diffs is not for discussions
of this sort.)