[PATCH 1 of 2 V3] revset: make desc() function accept multiple arguments

Alexander Plavin alexander at plav.in
Mon Sep 9 00:12:17 CDT 2013



09.09.2013, 07:15, "Augie Fackler" <raf at durin42.com>:
> On Sat, Sep 07, 2013 at 11:24:19PM -0500, Kevin Bullock wrote:
>
>>  On 6 Sep 2013, at 4:04 AM, Alexander Plavin wrote:
>>>  # HG changeset patch
>>>  # User Alexander Plavin <alexander at plav.in>
>>>  # Date 1377196193 -14400
>>>  #      Thu Aug 22 22:29:53 2013 +0400
>>>  # Node ID 9058d1306b28dcb57aaa7791924473a86661bef7
>>>  # Parent  cf26d9c918f6f0943f39e8116ca807da1e4e8525
>>>  revset: make desc() function accept multiple arguments
>>>
>>>  This provides a more convenient way to express a conjunction of
>>>  multiple desc() calls with single argument.
>>  I'm still pondering whether this is the right way to provide a
>>  shorthand. I'm inclined to say that multiple arguments should
>>  express _dis_junction ('or') rather than conjunction ('and'). But
>>  it's probably going to be confusing no matter which one we pick.
>
> I'm honestly not sure which one is intuitive. My initial reaction as a
> conjunction, but the second time I read the patch I actually expected
> it the other way (trying to think like the user that doesn't read
> docs, naturally).

Personally I use this (from this patch) keyword() as an analogue to simple hgweb keyword search (which means conjunction too), when want to give some other options (other revset functions) so just simple keyword search wouldn't work. So in my opinion it certainly needs to represent conjunction (and desc() as well, for consistency).

However, it's not critical for me to have these two patches accepted to the upstream, the functions are extended just for better convenience and don't give any new features.

>
>>  Alternatively, we could provide an 'any(...)' revset as a (sort of) shorthand for ORing all its arguments together. We already have an 'all()' that takes no arguments and means something else, though.
>>
>>  Or maybe the current syntax is just as compact as it's going to get
>>  without introducing too much ambiguity. Waiting to hear other
>>  people's thoughts.
>
> I'm not sure this is a common enough case to warrant its own shorthand
>
>>  pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
>>  Kevin R. Bullock
>>
>>  _______________________________________________
>>  Mercurial-devel mailing list
>>  Mercurial-devel at selenic.com
>>  http://selenic.com/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list