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

[Gregory Heytings]

> I strongly disagree with the necessity to make re-widening technically 
> impossible, I find it fundamentally incompatible with Emacs's philosophy 
> and can't see any practical justification here.

As I said earlier, offering a way to escape the locked narrowing right 
away simply means that the current solution isn't one anymore.  Elisp 
programmers would take the habit of using (widen-unlock) instead of 
(widen) in their programs, and in a couple of years we'll see again bug 
reports by users who cannot edit buffers with long lines.

> Just narrow and make sure jit-lock.el and font-lock.el don't 
> accidentally widen it.

Now I'm lost.  Isn't this what is happening right now: "narrow and make 
sure jit-lock and font-lock don't accidentally widen it"?  What am I 
missing?

> Any other accidental widening should be considered as a bug anyway (and 
> we could even easily cook up some ad-hoc advice to try and detect those 
> cases for people like me who like to run their Emacs with lots of extra 
> runtime debugging checks).

There are I fear too many bugs related to that problem (you just said that 
half of the modes in core do use widen), and it does not seem reasonable 
to hope that they will all be fixed anytime soon.  If at some point they 
are, the current solution will not be necessary anymore, and it will be 
very easy to reset the default value of long-line-threshold to nil.