GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

Message #1447 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 15 Aug 2022 01:07:08 +0300

On 14.08.2022 21:27, Eli Zaretskii wrote:
>> Date: Sun, 14 Aug 2022 21:14:00 +0300
>> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dgutov <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.