bug#15555: 24.3; Bidirectional display very slow with long lines

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Jerome L Quinn <jlquinn@us.ibm.com>,  15555@debbugs.gnu.org
> Date: Wed, 09 Oct 2013 08:26:58 -0400
> 
> >> And disabling bidi reordering completely eliminates the bad behavior.
> > If you can afford that, go for it.
> 
> IIRC this is the first report where setting bidi-display-reordering to
> nil is really the best recommendation we can offer (and where it
> apparently indeed helps significantly).

Actually, it's not my recommendation.  But the OP keeps claiming that
nothing else works for him.

My recommendation would be rather to make lines shorter.

> I consider bidi-display-reordering as a debugging tool rather than
> a user config, so I'm not very happy about this situation.

I'm not happy either (probably even less than you), but I'm not going
to agree that slow redisplay of 14K-character lines has anything to do
with bidirectional editing support.  _Anything_ that slows down
redisplay even a bit will have the same effect with such long lines,
e.g., JIT font lock, Flyspell, invisible text, you name it.  In fact,
even on a reasonably fast machine (mine is a core i7 screamer) Emacs
is unbearably slow with such long lines without reordering as well.
Maybe the OP has an unreasonably fast machine, but that just makes his
use case even more rare.

IOW, this is bug #13675, which has nothing to do with bidi.  As long
as the basic display algorithms are not changed to fix that bug, I'm
going to claim that bidi is not the issue here.