From: Jani Nikula <jani@nikula.org>
To: Jameson Graef Rollins <jrollins@finestructure.net>,
 notmuch@notmuchmail.org
Subject: Re: [PATCH 0/6] notmuch cli config changes
In-Reply-To: <871ucts54t.fsf@servo.finestructure.net>
References: <cover.1359495450.git.jani@nikula.org>
	<871ucts54t.fsf@servo.finestructure.net>
User-Agent: Notmuch/0.14+259~gdee88db (http://notmuchmail.org) Emacs/23.2.1
	(x86_64-pc-linux-gnu)
Date: Thu, 07 Feb 2013 08:43:34 +0100
Message-ID: <878v70lgbd.fsf@nikula.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Wed, 06 Feb 2013, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> On Tue, Jan 29 2013, Jani Nikula <jani@nikula.org> wrote:
>> Hi all, the goal here is to add support for --config=FILE option at the
>> notmuch top level (e.g. 'notmuch --config=FILE search foo'). In order to
>> achieve this neatly, I ended up moving config open/close to main() from
>> subcommands. This isn't a bad thing, because all notmuch commands opened
>> the config file anyway.
>
> Hi, Jani.  I appreciate you've put a lot of work into this series, but
> I'll be the same devil's advocate that I was to David previously.  Why
> do we need a command line option here when we already have an
> environment variable that handles just this?  Is there some benefit to
> having a command line option for this that I don't see?  I see this as
> another instance of an option that regular users will rarely use, if
> ever.

Fair enough.

In any case I see patches 1-4, and to an extent also patch 5, as useful
refactoring and cleanup. Also, if we ever end up having any top level
arguments that need to be passed to subcommands, I think patches 1-5 are
good prep work. The config struct could be extended to include both
settings from the config file and settings from the top level
arguments. But this is just a bonus in addition to the refactoring part.

> In general, I am a strong advocate of keeping the CLI slim.  IMHO,
> adding more options makes the interface clunkier, and the manual harder
> to parse, and I'm against adding things that a normal user would likely
> never use.  In retrospect, I should have had the same objection to the
> --format-version option, which I think could have just been an env var
> as well.

What is a "normal user"? I'm a user too.


BR,
Jani.