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

[Stefan Monnier]

>> `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.

But the problems can also affect buffers without long lines (just with
many lines).  Or the case of having a thousand buffers opened.  Or ...

>> 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.

If the major mode overrides the locked narrowing which causes the users
experience to be unbearable in long buffers, the users could set this
variable to override the override (while sending a bug report to the
major mode's maintainers and waiting for the bug to be fixed).

> 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.

Yes, your work is *really* appreciated in this area.  I'm just pointing
out that there's no point trying to make it technically *impossible* for
users to shoot themselves in the foot making redisplay too slow,
because there are still plenty of other ways they can shoot themselves
in the foot, and because every time we make something undesirable
impossible, we *also* make it impossible to do some desirable things
(even if we can't yet imagine what those might be).


        Stefan