On Mon, 23 Nov 2009 01:56:04 +0100, Jan Janak <jan at 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