bug#57245: 29.0.50; M-> in a large XML file (without long lines) is slow

[Dmitry Gutov]

On 17.08.2022 15:20, Eli Zaretskii wrote:
> > Date: Wed, 17 Aug 2022 15:14:07 +0300
> > Cc:57245@debbugs.gnu.org,monnier@iro.umontreal.ca
> > From: Dmitry Gutov<dgutov@yandex.ru>
> >
> > > > Which seems to be exactly the behavior the "font-lock narrowing" was
> > > > supposed to guard from?
> > > No.  It wasn't supposed to fix modes that foolishly scan the buffer
> > > from BOB to point.
> > You might want to choose words better.
> I did.
>
> > > It was supposed to fix modes which scan from the
> > > beginning of line, and that is (a) only a problem when lines are very
> > > long, and (b) much harder to solve in the mode itself, because
> > > font-lock very frequently uses anchored regexps and otherwise likes to
> > > start from BOL, and syntax processing also likes starting from BOL.
> > syntax-wholelines-max handles that problem.
> Only for syntax-related stuff.

font-lock-extend-region-wholelines uses that variable too.

> And we have yet to see whether it's a
> good enough job: that feature is too young to be sure.

Same goes for the long-line-narrowing business.

And for us to be sure, people would need to be able to try it and report 
problems. But as long as handle_fontified_props creates a narrowing with 
~5000 char radius, syntax-wholelines-max isn't even given a chance to do 
its job.