On Mon, 25 Sep 2017, David Bremner <david@tethera.net> wrote: > Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes: >> So from an implementation point of view, it's definitely cleaner/simpler >> to have an internally "explicitly unset" state for the CLI flags. > > I'm trying to separate-out/defer impliementation questions here, at > least until I'm clear on the UI. Patches 1-5 and 8 in this series would be non-committal refactoring and cleanup in the mean time. ;) >> From a CLI UI perspective: do we want to be able to send --foo=default >> for a boolean explicitly? > > I have the feeling that maybe Jani does, but I'm not sure (as sometimes > happens) why my way of thinking about it isn't the only obvious way ;). I'm undecided. Definitely maybe. Going by "worse is better", the implementation *does* impact the decision, at least it impacts my opinion. For example, I don't think we'll open the database before argument parsing even if that turned out to be "the right thing". Looking at the defaults from another angle, if we don't want the ability to set --foo=default explicitly, I still think passing ints as booleans to the argument parser and checking if a boolean is neither true nor false is the wrong thing to do. I'd also like to convert to stdbool more. But those should not be a reason to convert essentially boolean arguments to keyword arguments. I think we need a way to have the argument parser tell us if an argument was present or not. BR, Jani. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch