Re: [emacs-bidi] RTL support

[Gregg Reynolds]

Martin Duerst wrote:
> 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,

No, I was speculating that that might have had something to do with
modeling RTL digit strings as MSD-first.  Without that, you have
problems with math routines.  If we were starting from scratch today
that might not be a big problem, but in the 50s and 60s processor time
was hugely expensive, and most (business) computing was bean-counting.
There were probably good economic reasons at the time in favor of the
MSD-first design.  But that's idle speculation.

> then you seem to say that implementing LSD first is even more
> difficult/expensive than implementing bidi. I'd probably have

Not at all; only with respect to functions etc. that interpret digit
strings as numbers.

> 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.

Similar arguments were made on the Unicode list not too long ago.  Let's
please not open up that debate here ;), but for what it's worth I never
understood what the worry is.  Personally I don't see any possibility of
confusion, but others clearly do.

-gregg