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 --> thread-question. 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 > semantics). === > 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 > > 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. === > Hermann H. 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). > _______________________________________________ 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