From: Mark Walters <markwalters1009@gmail.com>
To: Jani Nikula <jani@nikula.org>, Michal Sojka <sojkam1@fel.cvut.cz>
Subject: Re: [RFC PATCH 0/2] cli: split 'notmuch address' from 'notmuch
 search'
In-Reply-To: <cover.1414839970.git.jani@nikula.org>
References: <87egtn2s4z.fsf@steelpick.2x.cz>
	<cover.1414839970.git.jani@nikula.org>
User-Agent: Notmuch/0.18.1+86~gef5e66a (http://notmuchmail.org) Emacs/23.4.1
	(x86_64-pc-linux-gnu)
Date: Tue, 04 Nov 2014 09:14:58 +0000
Message-ID: <87r3xj2up9.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: notmuch@notmuchmail.org
Precedence: list


On Sat, 01 Nov 2014, Jani Nikula <jani@nikula.org> wrote:
> On Sat, 01 Nov 2014, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
>> On Sat, Nov 01 2014, Jani Nikula wrote:
>>> On Fri, 31 Oct 2014, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
>>>> This option allows to configure the criterion for duplicate address
>>>> filtering. Without this option, all unique combinations of name and
>>>> address parts are printed. This option allows to filter the output
>>>> more, for example to only contain unique address parts.
>>>
>>> This patch finally makes me think we should have a separate 'notmuch
>>> address' command for all of this. We are starting to have two orthogonal
>>> sets of 'notmuch search' options, one set for search and another for
>>> addresses. I regret not following the series and then making the
>>> observation so late.
>>
>> To some extent it is true. The question is whether it would make sense
>> for 'notmuch address' to have options like --offset and --limit.
>> Probably not.
>>
>> I can prepare a new patchset implementing 'notmuch address' over the
>> weekend. It would be necessary to revert the last (or two) already
>> merged patch. What do others think?
>
> Here's a couple of draft patches to make the search/address command
> split happen with minimal changes.
>
> In my opinion the problem is primarily in the user interface;
> notmuch-search man page is growing intimidating to the user. I also
> think splitting the implementation completely would lead to too much
> code duplication, as there is plenty of common code. The idea here is to
> split the user interface for address searching now when we haven't made
> a release with the functionality, and we can more easily change the code
> behind the interface going forward. Plus we can more comfortably add
> address management commands to 'notmuch address' than 'notmuch search'
> as the need arises.
>
> I do have to say in the end I'm also fine with having everything in the
> notmuch search command if there's opposition to having two very similar,
> even if diverging, commands.

I like this change and have reviewed the large follow-up series. Would
this make it easy to support the generic notmuch options after the
command? In particular I often type/think notmuch search --help rather than
notmuch --help search.

Best wishes

Mark





>
> BR,
> Jani.
>
>
> Jani Nikula (2):
>   cli: add support for hierarchical command line option arrays
>   cli: add notmuch address command
>
>  command-line-arguments.c |  11 ++--
>  command-line-arguments.h |   1 +
>  notmuch-client.h         |   3 ++
>  notmuch-search.c         | 128 ++++++++++++++++++++++++++++++-----------------
>  notmuch.c                |   2 +
>  5 files changed, 95 insertions(+), 50 deletions(-)
>
> -- 
> 2.1.1
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch