[emacs-bidi] Re: RTL support

[Benjamin Riefenstahl]

Hi Gregg,


I am not an Emacs developer, and I don't plan to work on this issue
right now.  I also don't believe that you have brought up new
arguments to change the decisions about how this is to done in Emacs
in the future.  I do think that an occasional check of these ideas is
a good thing, though.

So this exchange is mostly about: "Would I personally find useful
software that worked along the lines hat you suggest."

Gregg Reynolds writes:
> Two things.  One is, directionality a design choice, not a
> reflection of some kind of objective reality.

The fact that Arabic and other scripts are written and read from right
to left is a design feature of the script that we can't just ignore
when we implement it in computers, we have to deal with it at some
level.  The question is at *which* level.

> There is no necessary relationship between the IO model implemented
> by an application and the corresponding textual representation,

Exactly.  Which is why Unicode put the complicated parts into the IO
model (for human IO) with BIDI reordering, while any software module
that doesn't have human IO can completely ignore the issue.  The same
goes for most software that directly implements human IO but uses
pre-fabricated building blocks for it (using e.g. GTK or Qt).

If OTOH you use visual ordering in the encoding you make life easier
for a few primitive versions of the IO and complicated for all the
rest of the software.  Not to mention that it makes it even more
complicated for more advanced - read: user-friendly - versions of IO.

There is a third possibility in our case, using visual order within
Emacs and only storing the text in logical order.  That is possible in
a simple text editor (and I am sure there are some of those around).
But Emacs does a lot more, of course.  Every module in Emacs that
needs to look at the logical order would have to make the reordering
anyway.  And as Emacs is about text processing that would probably be
a lot of modules.

That's the choice.  I personally prefer the first way of doing it.

> More important is that RTL has no necessary relationship to mixed
> content or bidi reordering.  If you only ever write documents in
> Arabic (Hebrew, Persian, Pashto, whatever) then why do you need
> bidi?

A large part (maybe still a majority) of the people that write Arabic
and Hebrew on computers write in more than just one language.  This is
even if you discount numbers and trademarks.

> To be clear: monolingual Arabic text is not mixed content, whether
> it contains digit strings or not.  So why should an Arabic user pay
> the Unicode tax of bidi support?

A large part of the user base right now does need mixed content.  So
you would get the tax of supporting several versions of software, the
software for people that don't need mixed content and another version
for people that do.  Even if the first version on its own might be
cheaper, on the whole this will get more costly.  Not to mention that
it would end up in a system where the "natives" get the "stupid"
mono-lingual software and the "experts" and the westerners can afford
the "intelligent" software for the mixed content.


benny