[PATCH 0/9] argument parsing fixes and improvements

Jani Nikula jani at nikula.org
Wed Sep 20 02:16:33 PDT 2017


On Wed, Sep 20, 2017 at 12:43 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On Tue 2017-09-19 23:39:20 +0300, Jani Nikula wrote:
>> I had some other things in mind, but ended up with this prep series
>> instead... The main thing is patch 6 adding --no-argument style negating
>> arguments for boolean and keyword flag args. The rest is mostly just
>> refactoring and tests to make that happen.
>
> this series looks like it does what it says on the label to me, though i
> haven't tested it.

Thanks for the review.

> I'm not sure that the ux improvement is particularly significant,
> though.  Is there a concrete advantage of offering --no-foo on in
> addition to an already-present --foo=false ?  do we *want* there to be
> many ways to achieve the same result in the cli?

Those are good questions, and up for debate. I was more interested in
getting the mask out behaviour for keyword flag arguments, and the
boolean part came practically free. Or, there was certain synergy in
having them behave similarly.

This started out as I was pondering the notmuch show options. There's
a hodgepodge of options to control the output: --entire-thread,
--body, --include-html. I'd prefer a --output=foo parameter to choose
stuff, like in notmuch address, but also with a way to disable default
enabled outputs. So you could combine, say, --output=entire-thread
--no-output=body --output=html. If we ever need to add even one more
output option to notmuch show, I think this'll be worth it. Even if we
have to retain the old stuff for backwards compatibility.

Now, I don't know if that's the best way to do this. Perhaps people
would prefer --output=!entire-thread or --output=no-entire-thread or
--output=entire-thread-disable or something. But the --no- prefix at
least has precedence in other software for booleans, and I think
that's a good reason to consider it. And having patches on the list
doing it one way generates better feedback and discussion than just
general musing on IRC.

I don't recall if we considered comma-separated values for multiple
outputs in e.g. notmuch address, say --output=sender,recipients but we
ended up with separate --output=sender --output=recipients instead.
Not sure if that's relevant in this discussion... perhaps if we want
to support that in the future. (Do we?)

> I'm a little concerned that "notmuch search --exclude" is a corner case
> that doesn't make a lot of sense here.

That was an unfortunate choice for an example. notmuch show --exclude
is a normal boolean option I was looking at. The search --exclude
option shouldn't be discussed as an example for anything. ;)

> Also, this series should update the bash bindings so that the --no-
> arguments are available.  And i think the documentation for the cli
> should also be updated to mention --no-foo, right?

Of course. But given that there's so much bikeshedding potential, I
decided to postpone that part. :) We also have mixed documentation of
boolean options as it is. Some just have --foo, others have
--foo=(true|false). Perhaps we use the former for default false
options, and the latter for default true options, but it's still a bit
inconsistent. With --no-foo support, we could document the default
true options with that, and it would convey the default as a bonus.

BR,
Jani.


More information about the notmuch mailing list