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

[Eli Zaretskii]

> Date: Wed, 10 Aug 2022 21:54:04 +0300
> Cc: 56682@debbugs.gnu.org, gregory@heytings.org, stephen.berman@gmx.net,
>  monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > No, because font-lock is much more important than the effect of the
> > BPA.  (Do you even understand what the BPA does, and did you ever see
> > it in action?  Without that, this part of the discussion is just waste
> > of time.)
> 
> I have looked at examples now. Seems important for text in pertinent 
> human languages.

Yes.  Which JSON isn't.  But most PL modes have comments and strings,
and that's where this is important.

> >> We could add (setq bidi-inhibit-bpa nil) to prog-mode, I suppose.
> > 
> > Not to prog-mode, that I won't agree.  But maybe for JSON files, if we
> > think they are unlikely to suffer.
> 
> Sure, maybe.
> 
> Where do we draw the line, though? Not in prog-mode because a .js file, 
> say, can have comments in Persian or Hebrew?
>
> By that measurement, JSON is fine (no comments supported). But JSON 
> contains a bunch of strings, could store localizations, etc.

I presume that JSON files are rarely for human consumption, so the
strings are not very important.  And they will rarely include R2L
characters to begin with.

> I suppose the contents of said strings can store i18n text, with the 
> expectation of a user being able to edit it.

If and when that happens, users can turn BPA back on.

> > There are no caches for a good reason: the Unicode Bidirectional
> > Algorithm that we implement results in very far-reaching non-local
> > effects of small changes.  Even inserting or deleting a single
> > character can dramatically change how the buffer looks on display very
> > far from the locus of the change.
> 
> In both directions?

Yes (IIUC what you mean by that).  The effect back happens rarer than
forward, but it does happen.