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

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 16 Aug 2022 10:24:18 +0000

>> I'm not sure I correctly understand what you mean, but it seems to me 
>> that the fact that the Org parser caches its results implies that Org 
>> doesn't need to access the whole buffer to make "local" decisions.  It 
>> can use the data in cache for everything that is outside of the current 
>> narrowing, and update the portion of the cache corresponding to the 
>> current narrowing. IOW, there is no need to maintain separate parser 
>> caches for each possible narrowing state.  Am I misunderstanding 
>> something?
>
> Cache existence is not guaranteed.
>

Can that cache not be created unconditionally when the Org file is opened?

>
> When cache does not exist, Org must widen. If not, the cache will be 
> valid only for the current narrowing.
>
> When cache do exist, Org may not need to widen. But that also mean that 
> widening has happened in the past when the cache was generated.
>
> At the end, Org does need to be able to widen safely. At least in some 
> cases.
>

That will always be possible.  What should better be avoided is to use 
widen (and to scan the whole buffer) in performance-critical places, such 
as fontification-functions.

Previous Next

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