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
As title says, the case sensivity is not respected any more when the search pattern contains capitals within brackets.
As an example, rg --smart-case '[EÉ]conomie'
returns also lowercase matches ("economie").
The text was updated successfully, but these errors were encountered:
I see. Under what circumstances should an uppercase literal be detected? Would \p{Lu} qualify? What about [[:upper:]]? Or what about [@-a], which contains A-Z?
There is an uppercase literal in the regex pattern itself. For example, [A-Z]foo contains an uppercase literal, and therefore the search would be case sensitive. Another example, foo\p{Lu} (where \p{Lu} is the set of all uppercase Unicode letters) contains no uppercase literals and therefore would be a case insensitive search.
There are no literal characters at all. For example, \p{Lu} contains no literals, and therefore should be a case sensitive search.
(2) is actually slightly tricky to implement because the regex parser is a bit too ambitious. e.g., After parsing, there's no actual way to distinguish \p{Lu} from its correspond character class as if it were manually typed by the user.
This is kind of why I hate the smart case feature and why it's not the default. In the simple case, it has nice behavior, but when your regex grows beyond literals, its behavior becomes unclear and less intuitive.
In the absence of input from others, I think I'd like to just implement rule (1) and call it a day. It would, for example, work in @ngirard's case.
As title says, the case sensivity is not respected any more when the search pattern contains capitals within brackets.
As an example,
rg --smart-case '[EÉ]conomie'
returns also lowercase matches ("economie").
The text was updated successfully, but these errors were encountered: