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

[Dmitry Gutov]

On 10.08.2022 19:08, Eli Zaretskii wrote:
> > 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,

It's much worse. In the aforementioned dictionary.json, with 
fully-featured font-lock (narrowing disabled in handle_fontified_props) 
the buffer is perfectly responsive to edit as long as I (setq 
bidi-inhibit-bpa nil). Even with show-paren-mode enabled.

Without that, however, simple navigation commands take a significant 
amount of time. These measurements are with show-paren-mode off:

Near BOB:

(benchmark 1 '(next-line 1)) =>
Elapsed time: 0.246551s
Elapsed time: 0.247237s
Elapsed time: 0.247392s

Near EOB:

(benchmark 1 '(next-line 1)) =>
Elapsed time: 0.059583s
Elapsed time: 0.040372s
Elapsed time: 0.059508s

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

That reminds me of "the user can always disable font-lock" and your 
dismissal of Alan's advice to change font-lock-maximum-decoration to 2, 
saying that we should have good editing performance OOTB.

> if they know they will never need to
> look closely at bidirectional text: the effects are hardly visible
> unless you actually read the text.

We could add (setq bidi-inhibit-bpa nil) to prog-mode, I suppose.

It already has a bidi-paragraph-direction setting anyway.

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

Perhaps a cache similar to syntax-ppss one could do the job? Not sure 
what would be the trafeoffs, though. Like, how that would change the 
performance in the simple case.