Backwards compatibility or sanity? help

[Fraser Gordon]

On 21/08/2016 15:26, hh wrote:
> Ali,
> probably it's about time that you give at RTL-lesson/blog/tutorial?
> Would be very appreciated.
>
>> Ali wrote:
>> the number of items in 'ab' is not an invariant of its read order,
>> unless you reverse the characters in the delimiter too.
>> When the item delimiter is 'aa', the items of 'baaa' are completely
>> different. What happens when the item delimiter has combining
>> characters and we're matching the precombined version?
> Not reversing the LTR-delimiter to a RTL-delimiter changes the delimiter:
> Isn't it planned to introduce RTL-multichar-delimiters to solve this?
>
>> For a more simple example of the issues here, what are the backward
>> and forward words of
>> "String without closing quote
> RTL and LTR (should) have exactly the same words/truewords (seen as a counted
> set) and the same number of words/truewords. Right?
>
> Anyway, this is not my point, because words/truewords cannot be empty
> (except as the non-existent ones 'out-of-bounds') contrary to items or lines.
>
> My point is, that a _trailing_ LTR delimiter 'item' or 'line' that is ignored
> becomes a _leading_ RTL delimiter (delimiter also RTL), for the same string.
>
> Thus the number of items or lines increases by one, because the LTR ignored empty
> 'item' or 'line' becomes a RTL not-ignored empty 'item' or 'line' respectively.
> And the result of "empty is among the items of" (should be an order-independent
> "element-of-check") may switch from LTR-false to RTL-true, for the same string,
> and for the same one-char-delimiter (or also reversed multichar-delimiter).
>
> Salut, Hermann

I think there's a bit of a misunderstanding here about how LiveCode
handles LTR and RTL: the two are only different when being displayed in
a field. At all other times, they are exactly the same. LiveCode always
stores text in reading order (that is, the order that the person
familiar with the LTR/RTL language in question would read the words) not
the order that the words would be displayed on screen. Using the
convention in Unicode where LTR text is in lowercase and RTL is in
uppercase, the string displayed as

three,TWO,ONE

would have in-memory storage order of

ENO,OWT,three

and, therefore, the items of the string would be "ONE", "TWO" and
"three" (in that order). If done otherwise, inserting a small piece of
RTL text into a larger LTR list would completely break processing!
Whereas, this way, "first" is a completely language-neutral concept. The
fact that the first item appears on the left-hand side is simply because
we're using an LTR language, not because LiveCode counts from the left.

The reason "three,TWO,ONE" has the first item displayed on the right is
because, in the absence of other information, the first LTR/RTL
character in the string determines the primary display order. If the
string had another item "zero" inserted before the first item, the
display order would change to

zero,ONE,TWO,three

with a storage order of

zero,ENO,OWT,three

Again, only display cares about LTR/RTL. For every other purpose,
strings are sequences of characters with no inherent direction.

If you're feeling confused about LTR/RTL, remember this: don't do
anything differently. Pretend it doesn't exist and LiveCode will do all
the hard work for you. There is nothing special about it except that
characters are displayed in a different order.

Fraser