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

[Stefan Monnier]

> I'd say it is realistic, based on the observation that half of the
> programming language modes in core do use widen, which they weren't supposed
> to do.

AFAICT, most uses of widen in lisp/progmodes is *not* within code
related to font-lock (unsurprinsingly, since font-lock.el has been
widening "for ever", so widening in the major mode has always been
redundant).

> But this discussion is leading nowhere.  If you could point out to an
> actual (or even potential) problem caused by this locked narrowing,
> apart from an occasional mis-fontification, that would perhaps help it
> to advance.

If I were maintainer I'd just refuse such a change without corresponding
escape hatch, based on the experience gained over the years about how
Emacs is and should be designed.

As a package contributor I just find it offensive that the C code would
go to extra trouble in order to cut me out under the premise that "Elisp
programmers would take the habit of using (widen-unlock) instead of
(widen) in their programs", which I read as "we have to protect ELisp
contributors from themselves".

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.
I just don't buy it.


        Stefan