[PATCH] revset: add experimental set subscript operator

[Matt Harbison]

On Fri, 30 Jun 2017 20:08:31 -0400, Jun Wu <quark at fb.com> wrote:

> Excerpts from Yuya Nishihara's message of 2017-06-30 23:58:43 +0900:
>> # HG changeset patch
>> # User Yuya Nishihara <yuya at tcha.org>
>> # Date 1498302078 -32400
>> #      Sat Jun 24 20:01:18 2017 +0900
>> # Node ID b7f6740b0e58c468ecc82296fe1ee0800a7e0582
>> # Parent  fe3419b41a456661a3d35ae963d06a203d4446a2
>> revset: add experimental set subscript operator
>>
>> It only supports integer indices as a beginning. See the following post
>> for further ideas.
>>
>> https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm
>
> Glad to see progress on new operators! The implementation looks good to  
> me.
>
> Maybe this is unnecessary bike-shedding, but I feel "[]" is more natural  
> for
> "indexing" purpose.  "{}" is used in templates which might be confusing.

That was my first thought too, but then I realized that I misunderstood  
the purpose of this.  "Subscript/indexing" makes me think something like  
'parents(.)[1] == p2(.)'.  But:

$ ../hg log -r 'parents(.){0}' -T "{rev}:{node|short}\n"
36963:578172de2e38
$ ../hg log -r 'parents(.){1}' -T "{rev}:{node|short}\n"
36964:c9925ed4a5f4

... which follows the linked message, now that I re-read it.  IDK if that  
kind of indexing is useful for revsets, but it would be for template  
lists.  I'd rather use [] for that, but Yuya commented about that here:

https://bz.mercurial-scm.org/show_bug.cgi?id=5534

> Templates may seem unrelated, but I think it could be embedded in  
> revsets in
> the future.  That enables more flexible queries, like "commits whose  
> author
> is the same as (antoher revset)'s author".  Template strings need some
> function to "bind" to a ctx, like: author(template(REV, "{author}")).
>
>> I'm not sure if the current semantics are the most useful and  
>> extendable.
>> We might want the way to select the nth ancestors/descendants in sub  
>> graph,
>> by e.g. 'follow(filename){-2}', which is completely different so the  
>> '{n}'
>> operator wouldn't be usable.
>>