PosEx variant for case-insensitive search

[AlexTP]

PosEx is ASM based so it's very fast. (Uses IndexWord ASM based func.)
For CudaText, I need variant with case-insensitive match, with WideChar/UnicodeString params.
It can avoid WidestringManager by using some callback (CudaText has such callback to make UpperCase/LowerCase for widechar. It don't use WidestringManager. It uses table lookup).
Please?

[marcov]

PosEx is ASM based so it's very fast. (Uses IndexWord ASM based func.)
For CudaText, I need variant with case-insensitive match, with WideChar/UnicodeString params.
Please?

Nope, it uses indexbyte.

But for unicodestring you would need to based on indexword, but that assumes there is a word based value to search for.

And this is hard because unicode (and unicode based case sensitivity) is simply hard. There is no chance that such version would even be in the same ballpark as the ascii version

[AlexTP]

Then we can make a trick- pass TWO UnicodeString params to PosExI (example name) - str1, str2 (uppercase and lowercase) - it is app's work to prepare them. CudaText will prepare them using its table lookup.

[ASBzone]

Then we can make a trick- pass TWO UnicodeString params to PosExI (example name) - str1, str2 (uppercase and lowercase) - it is app's work to prepare them. CudaText will prepare them using its table lookup.

Okay, but UPPERCASE and lowercase are only two options in the case-insensitive continuum.   What about CamelCase, or jUsTmIxEdUpCaSe?   

[CM630]

Just to mention:
In English the capital lettor for „i“ is „I“.
In Turkish the capital letter for „i“ is „İ“, while the capital letter for „ı“ is „I“. This is only a single exception, that I am aware of, there might be hundreds.
So lowercase and uppercase might be problematic.

[AlexTP]

>Okay, but UPPERCASE and lowercase are only two options in the case-insensitive continuum.   What about CamelCase, or jUsTmIxEdUpCaSe?   

PosExI wil search for Widechar - using chars from str1+str2 - it will need the Len(str1)=Len(str2) and will compare next chars wil pairs - str1_i and str2_i. If both compares are False, next char is bad. Otherwise, next char is ok.

[AlexTP]

>In English the capital lettor for „i“ is „I“. In Turkish the capital letter for „i“ is „İ“,

No, in Unicode we have single result for UpperCase(wchar).

[Thaddy]

>In English the capital lettor for „i“ is „I“. In Turkish the capital letter for „i“ is „İ“,

No, in Unicode we have single result for UpperCase(wchar).

No, wchar does not expand to unicodechar by itself. So that only partially works (UCS2 subset of UTF16 afaik)

[AlexTP]

If wchar is not in unicode surrogate range (my code has functions IsCharSurrogateLow/...High), then it's mapped to unicodechar. If it is in, we need next wchar2 to make unicodechar from 2 wchars.

[Thaddy]

If wchar is not in unicode surrogate range (my code has functions IsCharSurrogateLow/...High), then it's mapped to unicodechar. If it is in, we need next wchar2 to make unicodechar from 2 wchars.

Maybe UTF32 is a suggestion, because that maps to everything. (including both UTF8 and UTF16). It is expensive in space but cheap in compute.

[AlexTP]

No problem with my idea about str1+str2 (of same Len). If we have surrogate pair in str1, we must have the same surrogate pair in str2 (because Uppercase/Lowercase for surrogate pair doesn't change it AFAIK)