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: issues-unsubscr...@lucene.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to