Re: [emacs-bidi] RTL support

[Martin Duerst]

At 07:26 05/11/23, Gregg Reynolds wrote:

>1.  It was legacy, so Unicode had so support it.  Then they went berserk 
with it.
>2.  Whoever made that first fateful design mistake either didn't 
understand what he was doing, or else designing in the service of the 
Arabic/Hebrew/etc speaking community was not a priority (making Western 
software work for those languages cheaply was most likely the motivation, 
hence the desire to avoid handling LSD-first digits.  But that's just my 
speculation.)
Well, Unicode is of course about encoding all scripts of the
world, whatever the direction. It seems extremely obvious that
in that context, you'd try to come up, or adopt, a solution
that didn't only allow each script to work on it's own, but
also different scripts together. The final algorithm is
probably more complex than it really needed to be, but that's
similar for most standards. Calling it 'berserk' doesn't help
in my view.

Regarding LSD (least significant digit) first, that's of course
the crucial point. If you say that making Western software
work for RTL languages cheaply was the motivation for the
bidi algorithm, and for making RTL languages inherently bidi,
then you seem to say that implementing LSD first is even more
difficult/expensive than implementing bidi. I'd probably have
to agree with that: While the technical details of a single
LSD-first number are much easier, making sure that everybody
in the world always knows which numbers are MSD-first and
which numbers are LSD-first would be a very expensive nightmare.
Messing up things like 123 and 321 can easily get expensive.
Having text, rather than numbers, run the wrong way at times,
doesn't look better, but is much better re. error detection.


Regards,    Martin.