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

[Dmitry Gutov]

On 15.08.2022 14:51, Eli Zaretskii wrote:
> > Date: Mon, 15 Aug 2022 13:06:14 +0300
> > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > > And btw, I have very different impression of what happens with 100x
> > > larger narrowing on my machine and with unoptimized builds.
> >
> > Given what we've seen about your parse-partial-sexp's performance (10x
> > slower than mine), I would hope for someone to figure out why it's so
> > slow in your unoptimized build. But if it doesn't happen, you would
> > probably use a different threshold/narrowing radius (through customization).
> >
> > It would make sense for our defaults not to be tailored to this very
> > particular development rig.
>
> If you are willing to lose my ability to debug complex redisplay
> problems in many cases, sure, go ahead.

Why? You would customize an option to a lower value, and go on to debugging.

Though I guess reproducing the exact conditions on the user's machine 
might get harder sometimes.

> > > > 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.
> > >
> > > Since when is font-lock-fontify-region specific to a language?  It is
> > > as general as xdisp.c.
> >
> > syntax-propertize is general, and yet it invokes language-specific rules
> > (through syntax-propertize-function).
>
> Nothing prevents xdisp.c from invoking those same rules if needed.

True. We could basically rewrite any Lisp function we have in C 
(font-lock-fontify-region, for example).

And by doing that bar a lot of power users/potential developers from 
being able to read that code, debug and contribute improvements.