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

[Gregory Heytings <gregory@heytings.org>]

>
> `post-command-hook` also has been abused in all kinds of ways that suck 
> for the user if they have too-large buffers, or too many buffers, or too 
> many frames, or ...
>

Indeed.  Which is why you'll see on the feature branch that in buffers 
with long lines post-command-hook is now also subjected to a locked 
narrowing.

>
> We can even add a user-option to "re-lock" the widening which would 
> prevent the "unlock the widening" from working, so that users can 
> override a poorly-thought-out use of widening which makes their large 
> file unusable (tho I'd argue that you can get the same result with an 
> `advice-add`).
>

I don't understand what you have in mind here.  How would such a user 
option be different from (setq long-line-threshold nil)?  Do you mean that 
we should make it possible for users to fine-tune each and every aspect of 
the optimizations, with a bunch of user configurable options?

>
> Also, let's not forget that the speed impact of large buffers is not 
> limited to the redisplay, so trying to work extra-hard to eliminate all 
> possible cases of the redisplay spending too much time in large buffers 
> won't prevent "apparent lockups" where the time is spent in the command 
> (or some hook run at that occasion) rather than in the redisplay itself.
>

It is not limited to redisplay only, but by far the largest fraction of 
the speed impact is (or rather was) in redisplay, and asymptotically so. 
Commands that used to take minutes on a reasonably recent computer now 
take a fraction of a second, only because redisplay is now faster.