bug#56682: Fix the long lines font locking related slowdowns

[Dmitry Gutov]

On 10.08.2022 15:43, Eli Zaretskii wrote:
> > Date: Wed, 10 Aug 2022 12:31:24 +0000
> > From: Gregory Heytings<gregory@heytings.org>
> > cc:56682@debbugs.gnu.org,stephen.berman@gmx.net,monnier@iro.umontreal.ca,
> >      dgutov@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.