From: Mark Walters <markwalters1009@gmail.com>
To: Jani Nikula <jani@nikula.org>, notmuch@notmuchmail.org
Subject: Re: [PATCH 0/2] cli: Parsing. Add option NOTMUCH_OPT_INT_OR_BOOLEAN
In-Reply-To: <87lina8uqk.fsf@nikula.org>
References: <1331244944-7960-1-git-send-email-markwalters1009@gmail.com>
	<87lina8uqk.fsf@nikula.org>
User-Agent: Notmuch/0.11.1+309~g045f9e7 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Fri, 09 Mar 2012 05:11:54 +0000
Message-ID: <87399iicit.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list


Hi

On Fri, 09 Mar 2012 02:48:35 +0200, Jani Nikula <jani@nikula.org> wrote:
> On Thu,  8 Mar 2012 22:15:42 +0000, Mark Walters <markwalters1009@gmail.com> wrote:
> > The first patch adds a new command line parsing option
> > NOTMUCH_OPT_INT_OR_BOOLEAN for command line parsing which accepts
> > --verbose=3 and --verbose with the latter setting verbose to 1. It
> > also allows --verbose=0 so (with a little caller support) the user can
> > turn off boolean options.
> > 
> > It also means that extra options can be added to the command line
> > programs in a backwards compatible manner (e.g. if --verbose already
> > exists we could add --verbose=2).
> > 
> > The second patch uses this to make the --entire-thread option to
> > notmuch-show a NOTMUCH_OPT_INT_OR_BOOLEAN. In particular this allows
> > the caller to disable --entire-thread (with --entire-thread=0) when
> > format=json.
> 
> I'm afraid I find both of the patches a bit hacky. The first because
> it's more about optional arguments to options than int-or-bool. The
> second because it's more about detecting whether the user has provided
> an option than int-or-bool.

Yes to both of these (although I don't think of it has hacky). The
second of these is the important consideration.

> For booleans, I think the notmuch style would be to allow --foo=true and
> --foo=false in addition to just --foo (which implies true) so you could
> also disable booleans. I think this would be fairly simple to implement,
> and would require no changes to option parser users.
>
> With --entire-thread the bigger problem is detecting whether the option
> was specified by the user or not. It would be great if the option parser
> could provide this information, but it might take a while to get
> there... In the mean time, I think I would rather see a well commented
> local hack here initializing the notmuch_bool_t params.entire_thread to
> -1, and changing it to TRUE or FALSE if not already done so by
> parse_arguments().

I think these need to be considered together. There are three important
possibilities for a boolean option foo: 1) foo not mentioned 2)
--foo=false and 3) --foo=true (--foo as an alias) but the parser only
has a boolean to store this in. We could overload the boolean as you
suggest (it is really an int so should be safe) but that does seem
hacky. 

That was why I decided to make the parser set an int rather than a
boolean. Since there are not very many OPT_BOOLEANs currently in the
code I think my decision to allow general ints to be returned is a
needless extension, but I do think we wish to allow the 3 states of
UNSET, FALSE and TRUE. Otherwise we limit any future boolean options to
always have the same default regardless of other settings.

If people are happy with setting a notmuch_bool_t to -1 (for unset) then
that is definitely the simplest option. Or if people think that default
boolean options should not depend on other options then we can just add
this hack for --entire-thread.

Best wishes

Mark