You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new Parsley 4 lexer introduced various degrees of support for Unicode. It would be nice to extend this newfound support across to regular character parsing, in place of just using string. As such the following combinators should be added:
They use the specific name qualifier of Utf16 because it may be desirable in future to additionally add UTF-8 compliant combinators too, given it is also a popular encoding, albeit one not supported natively in Scala/Java. All of these combinators should be careful to provide good caret and position updating in the presence of multi-char codepoints (see #129)
The text was updated successfully, but these errors were encountered:
It's probably best to move these all to a parsley.unicode package, which can also support Int versions of all the other parsers. This will mean, hilariously, deprecating codePoint in the 4.5.0 pre-5 deprecation spree.
The new Parsley 4 lexer introduced various degrees of support for Unicode. It would be nice to extend this newfound support across to regular character parsing, in place of just using
string
. As such the following combinators should be added:charUtf16(c: Int): Parsley[Int]
satisfyUtf16(p: Int => Boolean): Parsley[Int]
stringOfManyUtf16(p: Parsley[Int]): Parsley[String]
stringOfSomeUtf16(p: Parsley[Int]): Parsley[String]
They use the specific name qualifier of
Utf16
because it may be desirable in future to additionally add UTF-8 compliant combinators too, given it is also a popular encoding, albeit one not supported natively in Scala/Java. All of these combinators should be careful to provide good caret and position updating in the presence of multi-char codepoints (see #129)The text was updated successfully, but these errors were encountered: