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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Fri, 05 Aug 2022 17:20:56 +0300

> Date: Fri, 5 Aug 2022 15:59:57 +0300
> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 01.08.2022 14:58, Eli Zaretskii wrote:
> 
> > As I wrote elsewhere, I'm okay with extending 'widen' so that it could
> > "unlock" the locked narrowing, which could then be used in major modes
> > that convince us their performance is adequate (or clearly announce in
> > their docs that they don't care about files with long lines ;-).
> 
> And to address the idea of "unlocking" the narrowing: I think I have 
> demonstrated that the remaining slowdown can be caused purely by the 
> length of the buffer and how long 'parse-partial-sexp' takes to parse 
> it.

No, you haven't demonstrated that.

> And of course the more, let's say, *complex* modes like CC Mode will opt 
> for unlocking narrowing right away because its font-lock logic has to 
> jump around to previously-saved positions in its syntax cache, which 
> will inevitably spam errors here and there when those positions are not 
> accessible.

CC Mode is extremely unlikely to happen in files with such long lines,
so what it does is largely irrelevant to this discussion.

Previous Next

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