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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 10 Aug 2022 18:44:53 +0300
> Cc: 56682@debbugs.gnu.org, stephen.berman@gmx.net, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> 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.

Like I said: it _is_ limited.  But the limitation is smarter than just
some arbitrary number of character positions, because it is tuned to
this particular processing.

Note that the effect of it in this case is not as dramatic as
font-lock: it does slow down C-n/C-p, but not catastrophically so, not
like we've seen with the files we used for the long-lines speedups.
And if someone does think it's a catastrophe, they can always disable
the BPA, perhaps even globally, if they know they will never need to
look closely at bidirectional text: the effects are hardly visible
unless you actually read the text.

> 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.

This is impossible without a complete redesign of how the bidi display
works: it saves no information in the buffer object, none whatsoever.
The information is recomputed every time the display code is called,
and only for the portion of the buffer that needs to be traversed or
displayed; then it is discarded.  There are no caches of any kind that
keep the information after redisplay has done its job.