bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 16 Aug 2022 12:17:10 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 57207@debbugs.gnu.org, yantar92@gmail.com
> 
> > We update UNCHANGED_MODIFIED in mark_window_display_accurate_1, so if 
> > the window completes its redisplay cycle "normally", whatever jit-lock 
> > does shouldn't matter for the next redisplay cycle, because 
> > UNCHANGED_MODIFIED will be updated from MODIFF.
> 
> Hmmm...  The fact is that using CHARS_MODIFF avoids rescanning the buffer 
> when "too many" text properties are changed.  With xdisp.c, the long lines 
> detection code is not called anymore when scrolling through the (initially 
> unfontified) buffer.  The original bug description (additional delays 
> between redisplay cycles in a large buffer) is probably caused by 
> needlessly executing that long lines detection code, at least that's 
> consistent with my earlier experiments.

That was also my guess.

(I do see the long-line detection code sometimes called while
scrolling through xdisp.c, but that's probably because my Emacs is
unoptimized, and so cannot keep up with the auto-repeat rate of my
keyboard when I lean on C-v; and so some redisplay cycles are
interrupted prematurely and don't get to
mark_window_display_accurate_1.)

> > What I don't understand is why enlarging the value of the threshold 
> > causes Emacs to "hang".  If it really is some kind of infloop, I cannot 
> > understand how issues like outdated UNCHANGED_MODIFIED could cause that 
> > only for some value of the threshold, but not for a smaller value.  I 
> > thought perhaps there are lines longer than 10000 characters, but none 
> > beyond 100000, but this turns out to be false, so with both values of 
> > the threshold that loop in redisplay_window should have scanned the 
> > entire buffer top to bottom in both cases...
> >
> > So I suspect something else is at work here.
> >
> 
> Yes, I suspect that this is another bug, separate from the original bug 
> Ihor described.  It might be a bug in find_newline1, in the backtrace he 
> sent, find_newline1 returns 10568710 and later 9679581.  It's not clear 
> however if that's in the same loop (he asked gdb to "continue" between the 
> two).

This part of my confusion is now off the table.  So the primary
suspect is something that causes UNCHANGED_MODIFIED fail to be
updated.