Jumping cursors

[Richmond Mathewson]

Um: this could be a "stupid Richmond" case rather than anything else as 
I populated cells FF001
to FF01E with Grantha Samyuktaksharas: and those in FF002 and so on 
behave perfectly well;
but FF001 could be a non-character which I had overlooked: If one goes 
here:

http://www.unicode.org/charts/PDF/UF0000.pdf

information regarding FF001 is not much use . . .

The Range: F0000 - FFFFF is the Unicode Supplementary Private Use 
Area-A; a bit like that area
in New Mexico.

Although "The entire plane is dedicated to private use with the 
exception of the last two code points."
would seem to imply that FF001 should cause me no problems.

The difficulty with Unicode is that as it is a standard that is always 
changing, and that document about
the Unicode Supplementary Private Use Area-A is from Unicode version 6 
(the current one is version 9).

So, back to the font editor and shift that character down to the other 
end of the list . . .

The Unicode convention's website suffers from a prolixity that largely 
serves to obfuscate rather than
explain, indulging in long sentences full of Latin neologisms.

Richmond.

On 1/5/17 10:36 am, Ali Lloyd wrote:
> 0xFF001 appears to be an invalid unicode character, residing in the private
> use area. When I try
>> set the text of the selectedText to numToCodepoint(0xff001)
> The text is replaced by a character that LiveCode appears to think is RTL,
> and the cursor splits as it does when placed 'ahead' of an RTL character in
> mixed text. If you replace all the text of a line with it, it will
> therefore place the cursor to the left of the character.
>
> Whether this is a bug or not depends on whether 0xFF001 *should* be treated
> as RTL or not. I kind of suspect it isn't, but making sure codepoints from
> the private use area behave correctly in a field is unlikely to be a high
> priority fix, unless you have a good reason for doing it!
>
> On Wed, Jan 4, 2017 at 11:49 PM Kay C Lan <lan.kc.macmail at gmail.com> wrote:
>
>> On Thu, Jan 5, 2017 at 5:26 AM, J. Landman Gay <jacque at hyperactivesw.com>
>> wrote:
>>> I'm a little surprised that works at all. The "selectedtext" returns a
>>> string, not a position. I'd use "selectedChunk" which would provide a
>>> character location, enabling you to set the cursor at a specific
>> position.
>> Whilst your definitions of 'selectedText' and 'selectedChunk' are
>> correct, the fact is that 'set the text of the selectedText to "abc"'
>> does replace whatever text you've hilited with whatever text you've
>> specified regardless of whether the text you've hilighted is a long
>> string, a short string or an empty string. The 'normal' result of
>> doing such is that the cursor ends up and the right hand end of the
>> new text, but apparently not so if the new text is
>> numToCodePoint(0xFF001)
>>
>> I think Richmond should file a Bug report because it does seem he's
>> found an anomaly, or at the very least, if there is a valid reason why
>> this is the case for 0xFF001 (and possibly others) then maybe a Note
>> in the Dictionary describing this situation would be useful.
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode