bug#56682: Fix the long lines font locking related slowdowns

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 6 Aug 2022 01:38:05 +0300
> Cc: 56682@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > So what you prefer IIUC would be to call fontification-functions with a 
> > locked narrowing to 1 MB if point is before that threshold, and to not 
> > call fontification-functions at all after that threshold?  That might be 
> > another doable approach.
> 
> If we have to support huge files with max responsiveness, then that 
> would be my preference, yes.
> 
> I don't see the point of using a "locked" narrowing for this, though. 
> Maybe not even a narrowing at all: just avoid calling 
> fontification-functions with START > value_of(large_file_fontification_max).

I don't understand why this would be a good idea.  First, if we are
able to fontify the first 1MB of a file, why won't we be able to
fontify the 2nd, 3rd, ... Nth 1MB in a similarly fast fashion?  Do you
assume that fontification must go to BOB, but will never go forward
towards EOB?  Why would we make such an assumption, especially with
long lines, where EOB could also be EOL?

Next, why assume that your personal preferences in this case will be
shared by everyone else?  I, for one, will find it very strange to
have font-lock suddenly disappear at an arbitrary point.  If we don't
want to make the assumption it will be good for everyone, your
proposal should be one optional behavior, but not the only one.

And finally, there's no way to restrict fontification-functions from
accessing the buffer beyond the first 1MB, even if we want to, without
something like the locked narrowing.

>  > emacs -Q
>  > M-: (setq long-line-threshold nil syntax-wholeline-max most-positive-
>  > fixnum) RET
>  > C-x C-f dictionary.json RET y ;; takes 160 seconds
>  > C-e ;; takes 200 seconds
>  >
>  > emacs -Q
>  > M-: (setq long-line-threshold nil) RET
>  > C-x C-f dictionary.json RET y ;; immediate
>  > C-e ;; not finished after 1200 seconds (20 minutes), I killed Emacs
> 
> I get what you're saying, but the approach does seem "right" to me 
> because it works, letting me view and edit dictionary.json with good 
> performance and behavior.

On a Core i9 machine and with an optimized build, I presume?  And with
"good" being your subjective judgment that places more importance on
fontification than on responsiveness?  That's not necessarily a good
data point on which to base our decisions regarding the default
behavior.

> Either way, I believe the change is at the right level of abstraction, 
> and if it has bugs, they should be solvable without major redesign.

Alas, Mr. ShouldBe is not available for this project, and probably
won't be any time soon.