[PATCH] revset: introduce the summary predicate

[Matt Harbison]

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
>> >>
>> >> This is similar to the 'desc()' predicate, however the search is  
>> limited to the
>> >> first line, which I couldn't figure out how to do with the existing
>> >> functionality.  Unlike 'desc()', this supports regular expressions.   
>> The
>> >> 'matching()' revset already treats the summary line distinctly from  
>> the full
>> >> description, but that finds similar revisions instead of searching  
>> with a
>> >> string.
>> >
>> > Looks like a great usecase to handle, I want that. However, are there  
>> reasons why:
>> >
>> > 1) We could not add full pattern support to desc()
>> > 2) We could not make this an extra keyworkd parameters of desc()
>> >
>> > Multiplying the revset predicate hurts discoverability, having less  
>> but more powerful predicate seems useful.
>>
>> I share your concern about discoverability.
>>
>> I started out editing desc(), but it's explicitly documented as case  
>> insensitive.  It seems confusing if matching for literals is case  
>> insensitive, but regex is case sensitive for the same predicate. (I  
>> vaguely recall that you can make regex case insensitive, but I think  
>> that would also surprise the user.)  I meant to mention that maybe we  
>> could add pattern support to desc() in addition to this, but forgot.   
>> The other stuff I looked at that supports patterns, like tag(), is case  
>> sensitive for both literals and regex.  That makes sense, since those  
>> search for identifiers.
>
> 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 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?

I'm about to submit a patch to add the current 're:' support to 'desc' in  
the meantime, to hopefully move this along.  I'd also be curious if you  
have thoughts on how to conditionally limit this predicate to the first  
line, without limiting future functionality.