bug#45898: 27.1; wedged in redisplay again

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

> On 2022-06-25,, at 8:29 , Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> 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.

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.

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

Yes, that's what I meant by lisp -> iterator, using the move_it* "API".

I left out the command-loop, but it's also something I'd consider a category.

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

I've seen that, and I think that's fine.

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

Might be something specific to German.  People say "I need that bug for the next release", and mean the fix, because they have the bug already :-).

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

No, I didn't think of that.

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

You mean a case, where small numbers of ticks sum up by calling these Lisp functions often enough?

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

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