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