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

[Gregory Heytings <gregory@heytings.org>]

> 
> I have eliminated two performance problems frim js-json-mode that are 
> uncharacteristic for font-lock in general.
>

This is where we disagree: they _are_ characteristic of font locking in 
general, in all modes (in core and in the wild) that use widen in their 
font locking routines and/or do complex calculations far away from the 
region that must be fontified.

>> although it is still too slow to my taste for larger files, e.g. I have 
>> to wait five seconds after M-> in a ten times larger JSON file). And 
>> the original problem is still present if you edit, for example, a 20 MB 
>> minified JavaScript file...
>
> Hence the new user option.
>

The goal of this effort is not, and never was, to make editing the 
dictionary.json file reasonably fast with an optimized build on a Core i9 
computer.  That file is, again, just an example.  The goal of this effort 
is to make editing any large file as smooth as possible, out of the box, 
regardless of the major (and minor) modes that are are enabled, even with 
a less efficient CPU, e.g. a Raspberry Pi computer, or a lower end laptop 
with its CPU running at a lower frequency.

Which is why fixing js-mode, and adding a json-mode, as you did, is a "too 
local" fix.  Of course, that doesn't mean what you did is useless; it only 
means that it cannot be considered as a general solution to the problem at 
hand.

I can only repeat that the only ways to improve font locking in a 
non-local way (or at least, the only ways that were identified in the 
discussions so far) are either to improve the speed of syntax-ppss by an 
order of magnitude, in which case it would perhaps become feasible to 
allow syntax-ppss to have access to the whole buffer, or to equip 
syntax-ppss with heuristics to make it work "as well as possible" even 
when it only has access to a portion of the buffer.