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.
Then the goal failed because we don't disable bidi hpa? It has a much more noticeable effect on editing that font-lock.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.
That's also easy to incorporate on the branch, as soon as somebody actually manages to implement that kind of heuristic for at least one major mode. But I'm not a fan of this approach TBH.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.