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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 14 Aug 2022 20:51:14 +0300
On 14.08.2022 19:24, Gregory Heytings wrote:
> 
>>
>> So being able to fine-tune the behavior makes sense. Certainly not a 
>> "maintenance nightmare".
>>
> 
> 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. 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?

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.




This bug report was last modified 2 years and 8 days ago.

Previous Next


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