GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
View this message in rfc822 format
On 10.08.2022 15:43, Eli Zaretskii wrote:
>> 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.
Shouldn't the scanner be limited by the same narrowing that the
long-line optimizations create? Given its existing effect on font-lock,
limiting bidi searches seems like a no-brainer.
Alternatively, I would perhaps propose to perform said searching at two
junctions: when the buffer is visited (and the text is inserted and,
thus, unavoidably read), and when the buffer is saved (perhaps at that
point Emacs might have info about the added ranges, to avoid searching
through the whole buffer). The downside would be that the first added
R2L character might be displayed incorrectly until the buffer is saved.
But the upside would be pretty huge.
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.