Removing StringCaseSense

[lexikos]

Who uses StringCaseSense and why?

Under what circumstances does one specifically want to

• use locale mode?
• ignore locale?

[kczx3]

Can’t recall that I’ve ever used it.

[Helgef]

Sometimes one have to use it, Switch - example 1, if you omit the C option for inputhook, which is perfectly reasonable, you have to use stringcasesense for the nested switch. If the code is supposed to work in any script that is.

I never wanted to use locale, I don't now if any of my code which needs to be case insensitive, could break if locale mode was used.

Cheers.

[nnnik]

I never got case-insensitivity as it is presented in AutoHotkey.

Code: Select all

MsgBox "ä"="Ä"
StringCaseSense "Locale"
MsgBox "ä"="Ä"

If you leave out the StringCaseSense, LocaleÄ is not case-insensitive equivalent to ä even though they are perfectly normal letters.
This is very suprising to say the least. To a new user that speaks another language this might come off as a revelation. The very thought that ä and Ä aren't the same letter when you don't care about whether they are large or not probably never crossed their mind. And now they are dealt this information with no hint to it in a very confusing context.
So they might just figure out that StringCaseSense, Locale is the way to go.

The new user might come across objects - which for internal reasons does not respect StringCaseSense.
And this user then discovers that there is no way around the fact that AutoHotkey is clearly wrong about the fact that ä is not Ä when you make it big:

Code: Select all

test := {}
test.Ä := "Hello1"
test.ä := "Hello2"
Msgbox test.Ä . "`n" . test.ä
StringCaseSense "Locale"
test := {}
test.Ä := "Hello1"
test.ä := "Hello2"
Msgbox test.Ä . "`n" . test.ä

No even worse when they send their script, that relies on Ä being case-insensitive equivalent to ä, to their friend in another country that script might break.


The easiest context I could come up with is a searchable list. In this searcheable list you probably want case-insensitivity.
To achieve case-insensitivity you might have to use Locale mode when special letters from one country are involved.
But what if multiple countries are involved? What if you want to use the same list in another country?

The solutions StringCaseSense supplies are at the bare minimum unsatisfactory.
It attempts to hide the fundamental fact that AutoHotkey, while supporting Unicode it never extended its case-insensitivity to the entire Unicode characterset.
We have a language in which A and B might be case-sensitive, while the rest of the alphabet is case-insensitive.

[Helgef]

hi

If you leave out the StringCaseSense, Locale Ä is not case-insensitive equivalent to ä even though they are perfectly normal letters.

Maybe perfectly normal to some, but might be quite exotic for others. Consider,

In Western European languages, the letter 'i' (U+0069) upper cases to a dotless 'I' (U+0049). In Turkish, this letter upper cases to a dotted upper case letter 'İ' (U+0130). Similarly, 'I' (U+0049) lower cases to 'ı' (U+0131), which is a dotless lowercase letter i. src.

Therefore, I think this makes sense,

Off or 0 (false): The letters A-Z are considered identical to their lowercase counterparts.

Cheers.

[nnnik]

Thats really poor decision making on the unicode consortium then.
In this context the turkish i should be different from the international I.
This only makes a stronger argument against case-insensitivity though.

[lexikos]

I'd intended to defer this longer while I do other things, but I've pretty much decided to remove A_StringCaseSense (and merge Helgef's changes that make it unnecessary). If someone has a problem with this, perhaps something more sensible (not having StringCaseSense 1 activate locale mode) can be added later. Or not.