This is the same issue, but it is interesting nonetheless:

<AlexDaniel> m: dd (0x0F75.chr x 2).uninames
<camelia> rakudo-moar 636a3c: OUTPUT: «("TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL
SIGN U", "TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL SIGN U").Seq␤»
<AlexDaniel> m: dd (0x0F75.chr ~ 0x0F75.chr).uninames
<camelia> rakudo-moar 636a3c: OUTPUT: «("TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL
SIGN AA", "TIBETAN VOWEL SIGN U", "TIBETAN VOWEL SIGN U").Seq␤»

Note that the order should be normalized.
On 2017-07-26 03:36:32, alex.jakime...@gmail.com wrote:
> Code:
> say (“\c[COMBINING OVERLINE]a” x 2).chars
>
> Result:
> 4
>
>
> Code:
> say (“\c[COMBINING OVERLINE]a” ~ “\c[COMBINING OVERLINE]a”).chars
>
> Result:
> 3
>
>
>
> Both should produce the same result (3). What happens here is “a” on
> one side is not being squished into one grapheme with a combiner on
> another side.
>
> Please note that combiners are not the only thing can cause this. Here
> is the same thing with ZWJ:
>
> Code:
> my $x = “\x[2695]\x[FE0F]a\x[1F468]\x[200D]”;
> say ($x ~ $x).chars;
> say ($x x 2).chars
>
>
> Result:
> 5
> 6
>
>
>
>
> I have a feeling that this is a known issue, and that there might be a
> ticket for this already. However, I couldn't find it.

Reply via email to