New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<[a..z]> ranges break grapheme awareness #5425
Comments
From zefram@fysh.orgBuilt-in character classes such as <lower> consistently accept any
Matching against a literal character or a <[abc]>-type enumerated
But a <[a..z]>-type range-based character class has inconsistent
The behaviour seems to be that if in NFC the first character of the I think a <[a..z]>-type range should, with respect to diacritics, behave -zefram |
From @smls
This facility is already available in the form of the :ignoremark flag (or :m for short). I'm pretty sure that <[a..c]> should match exactly the same thing as <[abc]>, and that ("b\x[308]" ~~ /<[a..c]>/) matching is a bug. |
The RT System itself - Status changed from 'new' to 'open' |
From @TimToadyThe code generator in nqp for char ranges was incorrectly using ordat and ordfirst to find the character to compare, which throw away information on synthetic characters. We now use the getcp_s instruction instead, which leaves synthetics negative, so that they drop out of the character range correctly (but only when :m is not specified, of course). nqp fix in 2df0a0656e4b20a72bd73e6d2b6214b584d095ac rakudo bump in fe90be01c6546e1dbb2ee7ff794e8b6ea1491268 Tests updated in 172f6945653ddbce944af1d7cae9ad956f3a70b9 |
1 similar comment
From @TimToadyThe code generator in nqp for char ranges was incorrectly using ordat and ordfirst to find the character to compare, which throw away information on synthetic characters. We now use the getcp_s instruction instead, which leaves synthetics negative, so that they drop out of the character range correctly (but only when :m is not specified, of course). nqp fix in 2df0a0656e4b20a72bd73e6d2b6214b584d095ac rakudo bump in fe90be01c6546e1dbb2ee7ff794e8b6ea1491268 Tests updated in 172f6945653ddbce944af1d7cae9ad956f3a70b9 |
@TimToady - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#128550 (status was 'resolved')
Searchable as RT128550$
The text was updated successfully, but these errors were encountered: