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: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, stephen.berman <at> gmx.net, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Wed, 10 Aug 2022 15:43:30 +0300

> Date: Wed, 10 Aug 2022 12:31:24 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 56682 <at> debbugs.gnu.org, stephen.berman <at> gmx.net, monnier <at> iro.umontreal.ca, 
>     dgutov <at> yandex.ru
> 
> > Inhibiting the BPA is an option if it is known that the buffer doesn't 
> > include ant R2L characters anywhere; otherwise some braces/parens could 
> > be displayed incorrectly mirrored.
> 
> But is there an efficient way to determine if that the buffer doesn't 
> include any R2L characters?

Not without searching the buffer, not that I know of.  If the buffer
includes only ASCII characters (which this one doesn't), i.e. its
sizes in characters and bytes are identical, we could deduce that
there are no R2L characters without any heavy lifting.

> > If you remove the 3 closing braces/brackets at EOB and the corresponding 
> > opening braces/brackets, does navigation become significantly faster?
> 
> Yes, removing the 3 brackets at positions 1, 22, 23 and 19538, 19539 and 
> 19540 solves that problem.  In fact, just removing the brackets at 1, 22 
> and 23 solves that problem.  You can see the same problem in 
> dictionary.json, just removing the first character makes C-n and C-p 
> faster at BOB.

Stephen said it had a much smaller effect than inhibiting the BPA.
But yes, very long bracketed text segments could be a problem.

Previous Next

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