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

[Stefan Monnier]

> I see what you mean now.  But I don't think it would work.  What I want is
> to take reasonable measures to ensure that Emacs remains responsive "in
> spite of" mode maintainers.

"Reasonable measures" is good.
But once you step into "impossible to circumvent", you start going
directly against the goals of Free Software (and Emacs) to empower the user.

>> because there are still plenty of other ways they can shoot themselves in
>> the foot,
> I'm curious, are there other ways for a regular user (*not* an Elisp
> hacker!) to make Emacs completely unresponsive with regular editing
> commands, starting with emacs -Q?

We've had enough bug reports over the years (and I experienced such
things many times as well), yes.  Usually linked to bugs in some
package, of course, but in many case it wasn't a clear-cut bug, just
some bad interaction of various elements.

> I'm curious again, because I cannot imagine what that could be either.

I suffer from the same lack of imagination, as I sure many others here
do.  To make up for that, we've learned to follow a philosophy of
empowering the users (and not imposing arbitrary limits just because we
couldn't think of good reasons to go beyond them).

> Also note that you can blame yourself if you don't like the locked narrowing
> idea.  See the following three lines which you added ten years ago in
> eval.c:
>
> /* Don't export this variable to Elisp, so no one can mess with it
>    (Just imagine if someone makes it buffer-local).  */
> Funintern (Qinternal_interpreter_environment, Qnil);
>
> and which make it technically impossible to do something, incidentally
> without providing a way for Elisp hackers to escape that impossibility.

:-)


        Stefan