On Mon 2017-09-25 08:34:13 -0300, David Bremner wrote:
> I think there is two different discussions one could be having here; one
> about the UI, the other about the implimentation.
>
> From the UI point of view,

Are you using the term "UI" to mean "API" here?  i tend to think of "UI"
as the CLI interface, which i think still has open questions (see below).

> it seems like the best thing is to use any
> configuration to set the default for a given boolean flag. Conceptually
> this would look something like (semi-pseudo-code)
>
>     try_decrypt = false;
>     
>     notmuch_database_get_config(notmuch, "try_decrypt", &try_decrypt);
>
>     parse_arguments(argc, argv, ...)
>
> We have 3 possibilities, with the latest specified one winning.
>
> In the implmentation, we need to cope with the fact that the database
> probably can't be opened until after the command line arguments are
> processed.

in my cleartext-index series, reading the config from the database
doesn't happen until it's needed, because it is deferred to the creation
of the indexopts object (which you can't get without a database).

So from an implementation point of view, it's definitely cleaner/simpler
to have an internally "explicitly unset" state for the CLI flags.

From a CLI UI perspective: do we want to be able to send --foo=default
for a boolean explicitly?

    --dkg