Backwards compatibility or sanity? help
hh at hyperhh.de
Sun Aug 21 14:06:48 EDT 2016
Thank you all very much for the detailed and patient information.
Yes, there was a big misunderstanding about RTL/LTR by me, because
language-script directions can be deliberately mixed ('bidirectional',
as I read in an LC 7 introductory blog).
From that I concluded erroneously a wrong in-memory storage order.
Also languages that can be written 'bidirectional', in not only one
script, or (quoted) passages in a language script opposite to the
current direction can make the string in question deliberately
complicated (at least for me).
I think that I understand your explanations (hope so..).
--> Except the case of a trailing item delimiter, Monte's original
If a string has the in-memory storage order of "ENO,OWT,".
Is empty among its items? What is its display?
> Mark W. wrote:
> Perhaps there's a misunderstanding here...
> If when you refer to rtl to mean rtl languages (such as Arabic) then there
> is nothing to do - rtl languages are stored in memory in logical order - ie the
> same way round as ltr languages. It is just the display which is changed.
> If you mean doing chunk searching from high indicies to low then that would just
> be equivalent to reversing the order of the chars in the target string and then
> using the current operations on it (from what you've said about the suggested
> Fraser G. wrote:
> 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
> would have in-memory storage order of
> 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
> with a storage order of
> 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.
> Hermann H. wrote:
>> 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).
More information about the Use-livecode