[PATCH] revset: introduce the summary predicate

[Yuya Nishihara]

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.david at 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 <yuya at 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.david at ens-lyon.org> wrote:
> >>>>> >> On 01/04/2017 07:04 PM, Matt Harbison wrote:
> >>>>> >> # HG changeset patch
> >>>>> >> # User Matt Harbison <matt_harbison at 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.