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

[Gregory Heytings <gregory@heytings.org>]

>
> But the problems can also affect buffers without long lines (just with 
> many lines).
>

Yes, and that's what sits next on my list: "too large" buffers.

>
> Or the case of having a thousand buffers opened.  Or ...
>

I don't think the "too many buffers" case is worth investigating. 
Because it won't lock Emacs suddenly, like what we had.  It could make 
Emacs gradually slower, in which case the user can take some appropriate 
measures.

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

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.

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

Yes, with that I agree.  But as Eli said, it's not users who shoot 
themselves in the foot, it's innocent users that are shooted in the foot 
by syntax-ppss and/or by mode maintainers who are not careful enough. 
And as I said its not technically impossible for this to happen, users can 
freely unset long-line-threshold (although that's not recommended of 
course).

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

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

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

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.