rmuir commented on code in PR #14192:
URL: https://github.com/apache/lucene/pull/14192#discussion_r1940403543
##########
lucene/core/src/java/org/apache/lucene/util/automaton/RegExp.java:
##########
@@ -436,6 +478,160 @@ public enum Kind {
*/
@Deprecated public static final int DEPRECATED_COMPLEMENT = 0x10000;
+ /**
+ * See {@link #UNICODE_CASE_INSENSITIVE} for more details on the set of
known unstable alternative
+ * casings
+ */
+ static final Map<Integer, int[]> unstableUnicodeCharacters =
+ Map.ofEntries(
+ // these are the set of characters whose casing matches across
multiple characters
+ entry(181, new int[] {924, 956}),
Review Comment:
didn't mean to come off short here,
But the hex is just a defacto standard, e.g. you'll see that representation
in all the unicode data files. It helps to have an unambiguous way to refer to
the same codepoint.
There's quite a few lucene code reviewers that can look at the hex digits,
and recognize things, maybe how many bytes it takes up in UTF-8, maybe whether
it is compatibility character that might explode (﷽), maybe what block it is in
and so on.
Since they are all codepoints (`int`), it will help to do them all in hex
like `0x1F602`, as you can represent all codepoints with it. Only bother with
the `\uXXXX`, when dealing with java's UTF-16 `char` type.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
