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

[Dmitry Gutov <dgutov@yandex.ru>]

On 14.08.2022 21:01, Eli Zaretskii wrote:
>> Date: Sun, 14 Aug 2022 20:51:14 +0300
>> Cc: 56682@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
>>   monnier@iro.umontreal.ca
>> From: Dmitry Gutov <dgutov@yandex.ru>
>>
>>> If the conclusion is, after some reasonable effort, that there is no way
>>> to make syntax-ppss significantly faster in one way or another in such
>>> cases, and that there is no way to make font locking reasonably accurate
>>> even when it doesn't have access to the whole buffer, it might make
>>> sense to provide user options to fine-tune the behavior.  But we are not
>>> there yet.
>>
>> Both conclusions lead to removing the applications of narrowing from
>> handle_fontified_prop.
> 
> We will not remove that, no.

Please look at the branch. It moves the (potential) narrowing from C to 
Lisp.

>> So how about we either do that (defaulting to accurate font-lock),
>> or merge the branch I proposed, and then continue on to the more
>> complex developments?
> 
> Please wait with requests to merge until I had time to review the
> branch.

Waiting, and thanks.

>> Implementing the "font locking reasonably accurate even when it doesn't
>> have access to the whole buffer" would also have to be implemented in
>> Lisp, so narrowing outside of font-lock doesn't make sense.
> 
> Cannot parse this, sorry.  I guess some typo?

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.

Does that parse? Not sure how to phrase it better.