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".
