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

From: Dmitry Gutov <[email-masked]>
Date: Wed, 17 Aug 2022 15:40:27 +0300

On 17.08.2022 15:20, Eli Zaretskii wrote:
>> Date: Wed, 17 Aug 2022 15:14:07 +0300
>> Cc:[email-masked],[email-masked]
>> From: Dmitry Gutov<[email-masked]>
>>
>>>> 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.