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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 14 Aug 2022 13:29:42 +0300
> Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > I know, but we are not doing only what is easy to do, do we?  We do
> > (or should do) what the users expect.  In this case, if we want to
> > fontify some relatively small portion of the document, it should be
> > the portion around where the file is first displayed.
> 
> There's no point in doing that. Either we narrow to some area around 
> point (might even using a larger radius like 1 MB), or we we only 
> fontify up to some position. The former easily creates bad fontification.
> 
> The alternative, of course, is to pay the price of syntax-ppss on larger 
> spans and wait the corresponding amount of time the first time the user 
> scrolls to EOB. That's what the current default on the branch does.

You are still thinking in terms of the original design of syntactical
analysis which strives to produce 100% accurate results.  That design
principle doesn't work with very long lines, so sticking to it would
indeed lead us to give up on solving the problem.

The better way is to acknowledge that some inaccuracies are acceptable
in those cases.  With that in mind, one can design a syntax analyzer
that looks back only a short ways, until it finds some place that
could reasonably serve as an anchor point for heuristic decisions
about whether we are inside or outside a string or comment, and then
verifying that guess with some telltale syntactic elements that follow
(like semi-colons or comment-end delimiters in C).  While this kind of
heuristics can sometimes fail, if they only fail rarely, the result is
a huge win.

> But as Gregory shows, when you get to _really_ large files (like 1 GB 
> JSON file in his example), pressing M-> will still make you wait (I have 
> to wait around 20 seconds).

Try with the latest master, it might have improved (fingers crossed).

In any case, the way to speed up these cases is to look at the profile
and identify the code that is slowing us down; then attempt to make it
faster.  (20 sec is actually long enough for us to interrupt Emacs
under a debugger and look at the backtrace to find the culprit.)

> >> So the "don't fontify past X" strategy is simply based on the idea
> >> that no fontification is probably better than unreliable and
> >> obviously incorrect one.
> > 
> > I disagree with that idea, but if someone agrees with you, they can
> > simply turn off font-lock.  As was already mentioned many times in
> > this endless discussion.
> 
> If someone agrees with me, they will simply be able to customize 
> font-lock-large-files to choose this strategy.

If that solves the problems in a reasonable way for very long lines,
maybe we will eventually have such an option.

> I'm still waiting for people to come forward with other major modes 
> which have the same kind of problems. Preferably ones that are likely to 
> be used with large files.

One such major mode and one such file was presented long ago : a
single-line XML file.