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

[Dmitry Gutov]

On 14.08.2022 21:27, Eli Zaretskii wrote:
> > Date: Sun, 14 Aug 2022 21:14:00 +0300
> > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > The implementation of the idea that Gregory mentioned (font locking
> > reasonably accurate even when it doesn't have access to the whole
> > buffer) will have to be done in Lisp anyway. So that's where the
> > narrowing should be applied too.
>
> I don't see how it follows.  If we decide (and I don't say we did, but
> if we do) that fontification-functions must run narrowed, then they
> will run narrowed, and the best place to do that is in the caller.

Only if we somehow decided that it makes sense to always use the same 
narrowing bounds. But as experiment shows, font-lock can use 100x larger 
narrowing, and still perform well.

Further, the thing which is going to call the language-specific 
safe-position-finding logic is likely to want to update the bounds of 
the narrowing (to then call syntax-ppss within those bounds, where START 
is a "safe" position).

So yeah, the font-lock related widen/narrowing logic should indeed live 
in one place. And until now it has resided in font-lock-fontify-region.