1 Return-Path: <cworth@cworth.org>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id D5C86431FC0;
\r
6 Thu, 26 Nov 2009 07:23:51 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
8 Received: from olra.theworths.org ([127.0.0.1])
\r
9 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
10 with ESMTP id NiUmosXFRe6y; Thu, 26 Nov 2009 07:23:51 -0800 (PST)
\r
11 Received: from cworth.org (localhost [127.0.0.1])
\r
12 by olra.theworths.org (Postfix) with ESMTP id 11A6F431FAE;
\r
13 Thu, 26 Nov 2009 07:23:51 -0800 (PST)
\r
14 From: Carl Worth <cworth@cworth.org>
\r
15 To: Jan Janak <jan@ryngle.com>, notmuch@notmuchmail.org
\r
16 In-Reply-To: <87pr7a5aaj.fsf@ryngle.com>
\r
17 References: <87pr7a5aaj.fsf@ryngle.com>
\r
18 Date: Thu, 26 Nov 2009 07:23:37 -0800
\r
19 Message-ID: <87bpips41y.fsf@yoom.home.cworth.org>
\r
21 Content-Type: text/plain; charset=us-ascii
\r
22 Subject: [notmuch] On "search-tags" vs. "search --for tags" (was:
\r
23 search-tags and tag completion in notmuch.el)
\r
24 X-BeenThere: notmuch@notmuchmail.org
\r
25 X-Mailman-Version: 2.1.12
\r
27 List-Id: "Use and development of the notmuch mail system."
\r
28 <notmuch.notmuchmail.org>
\r
29 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
30 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
31 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
32 List-Post: <mailto:notmuch@notmuchmail.org>
\r
33 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
34 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
35 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
36 X-List-Received-Date: Thu, 26 Nov 2009 15:23:52 -0000
\r
38 On Mon, 23 Nov 2009 01:56:04 +0100, Jan Janak <jan@ryngle.com> wrote:
\r
39 > I considered implementing 'notmuch search --output=tags' (as we
\r
40 > discussed in another email), but it turned out that:
\r
42 > * Having 'notmuch search-tags' would be consistent with Carl's
\r
43 > 'notmuch search-messages'.
\r
45 Yes, but I just put that out as an RFC. I didn't actually push it out in
\r
46 that form, (and my big concern was overwhelming the user with a lot of
\r
47 different top-level commands).
\r
49 > * 'notmuch search' supports other command line options (--first,
\r
50 > --max-threads, --sort) and these would only work when the user uses
\r
51 > the command to search for messages.
\r
53 Fortunately, the --first and --max-threads options are gone now. So some
\r
54 of that concern is gone now.
\r
56 > * 'notmuch search-tags' is easier on fingers than
\r
57 > 'notmuch search --output=tags' :-).
\r
59 We can shorten the command with something like:
\r
61 notmuch search --for=tags
\r
63 Is that any better? I don't love the '=' there, and might prefer:
\r
65 notmuch search --for tags
\r
67 But that complicates the option parsing just a bit, (which I shouldn't
\r
68 really care about since what we're designing here is an interface that
\r
69 is easy for the user).
\r
71 In any case, I don't expect people typing at the command-line to do
\r
72 things like search for tags nearly as often as searching for
\r
73 threads. And that's really the biggest reason I *do* want to put this
\r
74 functionality behind a command-line option. I'd like to have a fairly
\r
75 short number of top-level commands that are each something a person at
\r
76 the command-line would be likely to use fairly regularly.
\r
78 Thanks that are more likely to be used by scripts, (such as
\r
79 --format=html), should be hidden behind options.
\r