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

[Gregory Heytings]

> Also, I'm trying to imagine scenario that leads to such an abuse:
>
> - under normal circumstances, there are no long lines, so they'll never 
> hit a "locked" narrowing and it will thus never occur to them to use a 
> `widen-unlock`.
>
> - when they get a bug report with a locked narrowing because of long 
> lines, using `widen-unlock` naively is likely to lead to an immediate 
> performance problem, so it's unlikely they'll use it.

When I read this, I thought you had a point, but there's a fallacy in your 
reasoning: using widen-unlock is in fact not likely to lead to an 
immediate performance problem.  The long-line-threshold limit is 
sufficiently high to never be reached in "normal" files, but nothing would 
happen if you cross that limit by a small amount, and nothing would even 
happen at twice or even thrice that limit.

If a mode author gets a bug report that is caused by locked narrowing, 
there is something wrong in the way the mode fontifies the buffer.  There 
is no reason to require access the whole buffer to fontify a small chunk 
of that buffer.  IOW, using widen-unlock there is nearly always wrong (I 
add "nearly" to leave open the possibility that there might be an 
exception).

This is becoming so litigious (you're now telling me that you're offended) 
that I start to believe that the right thing might in fact be to 
completely disable font locking in such buffers.  Would "no highlighting" 
be better than "occasional mis-highlighting" from your point of view?