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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode