From: Carl Worth <cworth@cworth.org>
To: Jan Janak <jan@ryngle.com>, notmuch@notmuchmail.org
In-Reply-To: <87pr7a5aaj.fsf@ryngle.com>
References: <87pr7a5aaj.fsf@ryngle.com>
Date: Thu, 26 Nov 2009 07:23:37 -0800
Message-ID: <87bpips41y.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [notmuch] On "search-tags" vs. "search --for tags" (was:
	search-tags and tag completion in notmuch.el)
Precedence: list

On Mon, 23 Nov 2009 01:56:04 +0100, Jan Janak <jan@ryngle.com> wrote:
> I considered implementing 'notmuch search --output=tags' (as we
> discussed in another email), but it turned out that:
> 
>   * Having 'notmuch search-tags' would be consistent with Carl's
>     'notmuch search-messages'.

Yes, but I just put that out as an RFC. I didn't actually push it out in
that form, (and my big concern was overwhelming the user with a lot of
different top-level commands).

>   * 'notmuch search' supports other command line options (--first,
>     --max-threads, --sort) and these would only work when the user uses
>     the command to search for messages.

Fortunately, the --first and --max-threads options are gone now. So some
of that concern is gone now.

>   * 'notmuch search-tags' is easier on fingers than 
>     'notmuch search --output=tags' :-).

We can shorten the command with something like:

	notmuch search --for=tags

Is that any better? I don't love the '=' there, and might prefer:

	notmuch search --for tags

But that complicates the option parsing just a bit, (which I shouldn't
really care about since what we're designing here is an interface that
is easy for the user).

In any case, I don't expect people typing at the command-line to do
things like search for tags nearly as often as searching for
threads. And that's really the biggest reason I *do* want to put this
functionality behind a command-line option. I'd like to have a fairly
short number of top-level commands that are each something a person at
the command-line would be likely to use fairly regularly.

Thanks that are more likely to be used by scripts, (such as
--format=html), should be hidden behind options.

-Carl