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: Tue, 02 Aug 2022 05:27:44 +0300

> Date: Tue, 2 Aug 2022 00:50:10 +0300
> Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 01.08.2022 16:19, Eli Zaretskii wrote:
> >> Date: Mon, 01 Aug 2022 13:14:20 +0000
> >> From: Gregory Heytings<gregory <at> heytings.org>
> >> cc:dgutov <at> yandex.ru,56682 <at> debbugs.gnu.org,monnier <at> iro.umontreal.ca
> >>
> >>> You can maybe have that for C-p that follows M->, but wouldn't the wait
> >>> return, with a vengeance, if you insert a single character (because then
> >>> the buffer needs to be re-scanned)?  If so, we've gained nothing,
> >>> really.
> >> Fortunately no: the buffer doesn't need to be rescanned, syntax-ppss
> >> caches its result, to avoid having to rescan the whole buffer again and
> >> again.
> > But the buffer has changed, so the cache is not necessarily valid,
> > right?
> 
> syntax-ppss cache is a list of checkpoints spread along the buffer.
> 
> After a modification, only the checkpoints below it are invalidated (to 
> be recomputed on-demand later).

So a suitably-concocted replace command will still invalidate a lot of
that cache, right?

Previous Next

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