On Sun, 8 Jan 2017 13:59:36 +0100, Pierre-Yves David wrote:
> I'm not 100% sure of what Yuya actually has in mind but here is my
> understanding of the situation and how we could move forward.
>
> Currently:
> ----------
>
> desc(X) → X is customly matched as a case insensitive litteral,
>
> We have a "generic" pattern definition syntax used by various other
> reveset (implemented in "stringmatcher")
>
> foo(X)
> → X is matched as a case sensitive litteral
> foo('literal:X')
> → X is matched as a case sensitive literal (same as the above)
> food('re:X')
> → X is matched as a regular expression (case sensitive)
>
> Proposal: (might be what yuya says)
> ---------
>
> extend the string matcher to
>
> foo('literal:X')
> → X is matched as a case sensitive literal
> foo('icase-literal:X')
> → X is matched as a case insensitive literal
> food('re:X')
> → X is matched as a regular expression (case sensitive)
>
> Then, desc move to use string matcher (default to "icase-literal").
>
> We do not need a 'icase-re:' spec, because one can easily achieve it
> using 're:(?i)foo'
Exactly! IMO, the explicit "literal:" should be case-sensitive so my proposal.
And case-insensitive literal matcher can be build as a regexp object.
On Sat, 07 Jan 2017 22:23:33 -0500, Matt Harbison wrote:
> I don't do any work with locales, so this is probably a silly question.
> Does the fact that the API ignores the current locale mean that there are
> corner cases where it won't agree with the current method of
> encoding.lowercase() everything and comparing?
Good point. unicode.lower() is locale aware so encoding.lower() would be the
same, which is slightly different from re.I. But I think that is unintentional.
e38846a79a23 only mentions encoding issue, which would be a sort of Shift_JIS
problems, not a locale-dependent case sensitivity.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
