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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Gregory Heytings [2022-07-31 10:50:18] wrote:
>> Emacs is not in the business of preventing people from shooting themselves
>> in the foot.  If we need this narrowing to be enforced because Emacs would
>> otherwise crash, then it's OK, but if not, then we *should* provide a way
>> to undo it.
> And how do you define "crash"?

Core dump.

> Is Emacs becoming unresponsive because an operation takes say two
> minutes to complete and cannot be interrupted a "crash"?  Or is
> a "crash" only a segfault?

Try `M-: (use-global-map (make-keymap)) RET`
Should we prevent users from doing that?

Let's focus on making it easy to make it work well, rather than making
it impossible to make it work poorly.

>>> BTW, my tests show that syntax-ppss can be rather slow, when the file is
>>> large enough (say 1 GB).
>> No doubt.  But it's no slower with long lines than with short lines.
>
> Yes, I wasn't clear enough, I should have written "when the file is large
> enough (say 1 GB), even without long lines".
>
> But you didn't answer my question: is it not possible to design a version of
> syntax-ppss that would approximate, with some heuristics, what syntax-ppss
> does, but on a smaller chunk of the buffer?

The answer is basically "no" but even before getting there, I have to
remind the reader that it hasn't really been requested.

In order to know if POS is within a string (which is one of the main
uses of `syntax-ppss`), you basically need to know if there's an odd or
even number of quotes before POS, which fundamentally needs to look at
all the chars between POS and BOB.  Of course we use a cache to try and
avoid looking at them over and over again, but the cache can't be of any
use the first time around.


        Stefan