[PATCH 8 of 8 v2] help: mark boolean flags with a ^ and explain that they can be negated (RFC)

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Sep 6 16:09:31 UTC 2016



On 08/31/2016 07:10 PM, Augie Fackler wrote:
> On Wed, Aug 31, 2016 at 12:13 PM, Matt Mackall <mpm at selenic.com> wrote:
>> On Tue, 2016-08-30 at 16:16 -0400, Augie Fackler wrote:
>>> # HG changeset patch
>>> # User Augie Fackler <augie at google.com>
>>> # Date 1472584444 14400
>>> #      Tue Aug 30 15:14:04 2016 -0400
>>> # Node ID 5efc13a760938ff5fd8e4553dd8e06d06b98025b
>>> # Parent  fd68fb86c29873eb32c4a2bd28f7ac0abe3dc172
>>> help: mark boolean flags with a ^ and explain that they can be negated (RFC)
>>
>>
>>>  options ([+] can be repeated, flags marked ^ can be negated with --no-):

I like the general idea.

>> The format here is a bit inconsistent. Perhaps:
>>
>>   options ([+] can be repeated, [?] are flags):

What  about [&], "?" is a bit confusing to me as we often use it for 
optional/extend help thingy. "&" is often related to boolean/bit 
operation and seems to fit here.

>> I think actually sticking ^ on the option name itself is a little bizarre and
>> might lead to some minor confusion.
>>
>> Also, we should probably figure out a way to have aliases for some of these
>> options so we can fully normalize the scheme. Consider:
>>
>>> +   -y --noninteractive^   do not prompt, automatically pick the first choice
>>
>> Having --no-noninteractive seems really sad. We could make --noninteractive
>> hidden and then advertise --no-interactive as the long version.
>>
>> Also, I don't think --no-no-backup is a good idea. --backup should be its
>> negation.
>
> These cases are a bit problematic, because we don't really have a way
> to specify default-true flags. Would it be good enough to blacklist
> anything that starts with no- and noninteractive for now?

Can you elaborate on this. I saw your changeset making it forbiden as a 
default value (because it was silly) but is seems like we found 
non-silly usecase. Is there a technical reason why we don't want default 
value to True?


>>> +      --version^          output version information and exit
>>> +   -h --help^             display help and exit
>>
>> Wat. That's maybe a little too generalized.
>
> Heh. Yeah. I can blacklist specific flags, I guess.

If this is a common issue, we could consider using some special marker 
(or special default value) in the option definition. But the list will 
probably be short and that won't be worth the trouble.

-- 
Pierre-Yves David



More information about the Mercurial-devel mailing list