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

[Dmitry Gutov <dgutov@yandex.ru>]

On 15.08.2022 22:36, Gregory Heytings wrote:
> 
>>
>> No, I want a simple variable that just gives the size of the narrowed 
>> region, with nil meaning don't narrow at all.
>>
> 
> FWIW, I strongly object to the addition of such a variable (unless it is 
> clearly stated that it is added temporarily and should not be used 
> except for testing purposes).
> 
> Adding such a variable only two weeks after locked narrowing has been 
> introduced means that modes will have little incentive to adapt to that 
> stronger constraint, if they can "fix" whatever problems that constraint 
> might cause by setting that variable to nil in their initialization hooks.

I don't think major modes would take advantage of that var. I hope not, 
at least.

> We did not have enough time yet to explore whether and how syntax-ppss 
> can be improved.

If you wanted the development to take this route, it would have really 
made more sense to hold off on applying the narrowing to 
fontification-functions, keeping font-lock slow-ish in large files. That 
would have encouraged direct work on speeding it up.

But anyway. Suppose we have some more success with syntax-ppss. Two options:

1) parse-partial-sexp is now faster by 10x. That just means we have 10x 
larger files to deal with.

2) We have learned to find a "safe position" in some file types, to 
avoid the full scan from the beginning. It's not hard to implement that 
for JSON and XML, as long as we can stand _some_ imprecision. But there 
will remain all other file types for which nobody has written such logic.

In both cases we fall back to something. And the preceding discussion 
has concluded that that something is narrowing.