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
>>
>> 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.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
