Am 24.07.23 um 22:50 schrieb Junio C Hamano:
> René Scharfe <l.s.r@xxxxxx> writes:
>
>> Am 24.07.23 um 20:51 schrieb Junio C Hamano:
>>> René Scharfe <l.s.r@xxxxxx> writes:
>>>
>>>> Am 21.07.23 um 22:09 schrieb Junio C Hamano:
>>>>> René Scharfe <l.s.r@xxxxxx> writes:
>>>>>
>>>>>> - -D, --no-doubt begins with 'no-'
>>>>>> + -D, --[no-]no-doubt begins with 'no-'
>>>>>
>>>>> Hmph, I really really loved the neat trick to allow "no-doubt"
>>>>> option to be "positivised" by _dropping_ the leading "no-" at around
>>>>> 0f1930c5 (parse-options: allow positivation of options starting,
>>>>> with no-, 2012-02-25).
>>>>
>>>> Yeah, if there is a better way to document A) that the "no-" is optional
>>>> and B) whether it's present by default, I'm all ears.
>>>
>>> Some options take "no-" prefix while some others do not, so
>>> indicating that "this can take negative forms" vs "this do not take
>>> negative forms" by "--[no-]xyzzy" and "--frotz" makes sense.
>>>
>>> Yikes. There are tons of options whose names begin with "no-" and
>>> marked PARSE_OPT_NONEG, so "an option '--no-nitfol' that does not
>>> have the 'no-' part in [brackets] can drop 'no-' to make it
>>> positive" would not fly as a rule/convention.
>>>
>>> If we do not mind getting longer, we could say
>>>
>>> -D, --no-doubt, --doubt
>>>
>>> and explain in the description that --no-doubt is the same as -D and
>>> --doubt is the default. It is making the developers responsible for
>>> clarify, which is not very satisfying.
>>
>> Adjusting all explanations manually seems quite tedious.
>>
>>> We may not reject "--no-no-doubt" but with the positivization
>>> support, double negation is not something we'd encourage without
>>> feeling embarrassed.
>>
>> Right. Perhaps --[[no-]no-]doubt? Looks a bit silly with its nested
>> brackets, but it's more correct, because it documents all three accepted
>> forms, including the no-less one.
>
> It may look a bit silly but looks very tempting. Also it is not
> much longer than "--[no-]no-doubt".
Yes, it's quite compact. But is it they still legible?
--no-index find in contents not managed by git
--[no-]no-index find in contents not managed by git
--[[no-]no-]index find in contents not managed by git
--[no-[no-]]index find in contents not managed by git
The last two document all three variants, but is it still obvious that
the help text is supposed to be about the one with a single "no-"?
That's something that has to be learned, I suspect. No good making the
short help too cryptic. Hmm, how about:
--no-index, --[no-[no-]]index
find in contents not managed by git
Somewhat redundant, but highlights the documented variant.
René
