bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Sat, 09 Jul 2022 10:50:26 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, larsi@gnus.org, 56393@debbugs.gnu.org
> 
> > I'm asking whether applying the "restriction" where we call 
> > Vfontification_functions from the display engine won't also solve 3.
> >
> 
> It doesn't, see again the long-line-excerpt.xml file I sent you.  It is 
> only 30K long, which would be a typical size for a restriction, and 
> editing that file is slow when font locking is on and fast when font 
> locking is off.

I guess it's because we leave ZV at its original value, and font-lock
attempts to fontify the entire long line till the end?  Does it help
to make the value of syntax-wholeline-max smaller?

> What I would do (but I'm pretty sure you wouln't agree with that) is to 
> measure the time taken by fontification-functions in 
> handle_fontified_prop, and whenever that time is above a certain threshold 
> (say 0.25 or 0.5 seconds), to set fontification-functions to nil in that 
> buffer.

You could instead look at the value of the "redisplay tick count"
collected by update_redisplay_ticks.  (That is only called if
max-redisplay-ticks is non-zero, but you could set it to some large
value, so that it never actually signals an error.)

> But fontification-functions are not the only problem here.  What I also 
> observe is that, for example, moving in a fontified buffer takes (much) 
> longer than moving in a non-fontified buffer.  For example, in 
> long-line.xml, vertical-motion takes about 40 ms backward and 10 ms 
> forward in a non-fontified buffer, and about 180 ms backward and 40 ms 
> forward in a fontified buffer.

I guess that's because vertical-motion calls the display code, and
that calls fontification-functions.