On Mon, Apr 27 2020, Daniel Kahn Gillmor wrote: > On Mon 2020-04-27 14:53:07 -0300, David Bremner wrote: >> Quoting notmuch(1) >> >> OPTION SYNTAX >> All options accepting an argument can be used with '=' >> or ':' as a separator. For the cases where it's not ambiguous >> (in particular excluding boolean options), a space can also be >> used. > > This is a pretty twisty way to say what we mean. Are there other cases > besides boolean options? If there are, perhaps it'd be clearer to say > something like this for the last sentence: > > Except for boolean options and other potential ambiguous cases, a > space can also be used as a separator. > > If there aren't, we could say: > > Except for boolean options (which would be ambiguous), a space can > also be used as a separator. > > Alternately, we could deprecate using whitespace for all options, > produce explicit warnings to stderr when whitespace appears on the next was it so, that originally we did not support whitespace, but David added that in some commit... > release, remove the suggestion to use a whitespace separator from the > documentation, and eventually phase it out entirely in some future > release. Alternatively we could check that next arg is (case-insensitively) (subset of) 'true', 'false', 'yes', 'no', '0', '1', 't', 'nil' (but not tpyoes of these ;) and in that case have that as an option value... ... would that work better for human user who just wants to be fluent on command line -- frontends can then always use = and option values... > --dkg Tomi _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch