On Mon, 9 Jan 2017 11:49:23 +0100, Pierre-Yves David wrote: > > > On 01/08/2017 09:34 PM, Matt Harbison wrote: > > On Sun, 08 Jan 2017 07:59:36 -0500, Pierre-Yves David > > <pierre-yves.da...@ens-lyon.org> wrote: > > > >> (ha, I wrote my previous reply in a train and it got sent when I > >> connected again (and received that one). I'm going to try to adress > >> the new content in this email and sometime repeat some of my other > >> reply content for clarity) > >> > >> On 01/08/2017 04:23 AM, Matt Harbison wrote: > >>> On Sat, 07 Jan 2017 02:56:48 -0500, Yuya Nishihara <y...@tcha.org> > >>> wrote: > >>> > >>>> On Fri, 6 Jan 2017 21:29:43 -0500, Matt Harbison wrote: > >>>>> > On Jan 6, 2017, at 11:19 AM, Pierre-Yves David > >>>>> <pierre-yves.da...@ens-lyon.org> wrote: > >>>>> >> On 01/04/2017 07:04 PM, Matt Harbison wrote: > >>>>> >> # HG changeset patch > >>>>> >> # User Matt Harbison <matt_harbi...@yahoo.com> > >>>>> >> # Date 1483550016 18000 > >>>>> >> # Wed Jan 04 12:13:36 2017 -0500 > >>>>> >> # Node ID 76d95ab94b9e206363629059fb7824002e19a9e5 > >>>>> >> # Parent 0064a1eb28e246ded9b726c696d048143d1b23f1 > >>>>> >> revset: introduce the summary predicate > >>>>> >> > > > >>>> Perhaps stringmatcher can have 3 types, icase literal, literal, and > >>>> re, and > >>>> the default of desc() is icase literal for backward compatibility. You > >>>> can > >>>> build a case-insensitive regexp object from a literal pattern. > >>>> > >>>> https://docs.python.org/2/library/re.html#re.I > >>> > >>> Yep, that's the API I was thinking of. > >>> > >>> I'm confused by the rest of your comments. When I first skimmed your > >>> message, adding support for 'icasere:' using this API popped into my > >>> mind. And that could support a case insensitive literal, because > >>> 'icasere:foo' should be equivalent to looking for the substring 'foo' > >>> (leaving aside efficiency, how discoverable that is, and that > >>> stringmatcher matches the whole string for literals). But you seem to > >>> be suggesting adding 'icaseliteral:'. > >> > >> 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 > > > > See the comment in the new patch I sent about 'user()' already > > lowercasing 'literal:' and 're:'. I'd consider it a bug, but it's been > > in since mid 2012. Attempting to channel Matt, I'm guessing we are > > stuck with that since it is so old, but wanted to see what others think. > > 1) Yep, we are stuck with whatever existing behavior we have for > existing predicate because of BC. (but we can augment it)
Uh, user() does lowercase the regexp pattern, which is obviously wrong as you said. I hope this weirdness will be narrowed to user() even if we can't fix that. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
