bug#9571: 24.0.50; user option to turn off bidi, please

[Eli Zaretskii]

> From: Štěpán Němec
>       <stepnem@gmail.com>
> Date: Fri, 23 Sep 2011 10:01:08 +0200
> Cc: 9571@debbugs.gnu.org
> 
> On Fri, 23 Sep 2011 06:11:16 +0200
> Stefan Monnier wrote:
> 
> >> Can you imagine that there are some Emacs users who do not _ever_ need
> >> or want to edit bidirectional text?
> >
> > If those users get a different behavior depending on
> > bidi-display-reordering, then we have a bug.
> 
> I assume you don't consider UI responsiveness (buffer movement etc.)
> deterioration a bug, then?

Yes, I do.  Please report them as much as possible, so they could be
debugged and fixed.

> AFIAK it's totally unrealistic to expect the same responsiveness
> from Emacs with bidi enabled as from one with bidi disabled

No, it's not unrealistic.  In a vast majority of cases, the difference
in responsiveness is below the threshold of human perception.  If it
were not for that, we would have much more complaints about the new
display.  Where it exceeds that threshold, i.e. it becomes annoyingly
slow (whatever "annoyingly" means for you), please report that as a
bug with a clear test case.  Without reporting such incidents, there's
no way we can get the new display better as fast as needed, which I
hope is what everyone here wants.

> just as is the case with font locking.

This analogy is invalid, because font-lock is a very different beast.
For starters, it works on the entire buffer, while bidi is
display-only feature, and thus operates only on the (small) portion of
the buffer being displayed.

> OTOH, I understand you probably just want to push bidi down everybody's
> throat

No one around here has such a nasty attitude.  I'm appalled that you
can even suggest such a possibility.  The bidi display was designed
and implemented to be fast enough to be tolerable by people even if
they don't use any R2L scripts.  Where the reality flies at the face
of this design or implementation, there's a bug that needs to be
fixed.  But it's impossible to fix them if they are not reported,
because Emacs display features are a million, and no single living
person can envision every use case in a lifetime.

> the argumentation so far seems a bit disingenuous to me.

They are the truth nonetheless.  The old unidirectional display was
left in place only as a debugging aid.  Like any other basic feature
of the display engine, it will one day become the only way to display
text in Emacs, because maintaining two separate code bases, and in the
display engine at that, is a serious maintenance burden.  Introducing
a user-level variable to use the unidirectional display will be a
tremendous obstacle when we would like to get rid of the old code, I
hope at least that much is clear and agreed.