Re: [PATCH 2/2] notmuch list: A new command to produce various lists.

[Carl Worth <cworth@cworth.org>]

On Sat, 21 Nov 2009 22:07:14 +0100, Jan Janak <jan@ryngle.com> wrote:
> My patch no longer works and I have been thinking about updating it to
> current HEAD. But before I do that, I wanted to check with you to see
> if you would prefer to use a different name for the command, here are
> some options:
> 
>   1) notmuch tags
>   2) notmuch list tags
>   3) notmuch list-tag
> 
> Any opinions?
> 
> I also plan to add support for search-terms later so that we can
> produce tag lists for a set of messages, as you mentioned in one of
> your previous emails.

I don't think "list" would make sense unless it didn't support search
terms at all.

So I proposed my "search-messages" command earlier as well.

It's clear that there are lots of different things that we're going to
want to search for in the database and then lots of way's that we're
going to want to present the resulting data.

I would rather like there to be some correlation between commands with
shorter names being more likely to be the kind of thing that a user
would use directly from the command line. And longer names can be used
for things that are more for interfaces to use, and for people to use in
writing scripts.

So how about "search-tags" and "search-messages" ?

Any better ideas?

Another option would be to just call this "notmuch search" and have an
option to control what is output:

       notmuch search	# for threads, as currently
       notmuch search --output=tags
       notmuch search --output=messages

Actually, I kind of like that. For one thing, it makes it easy to
eliminate the redundancy I made with the option-parsing in both
notmuch-search.c and notmuch-search-message.c.

> A quick description for those who joined later: This command produces
> a list of all tags defined in the database. The emacs interface uses
> it to implement tag name completion.

And I can't wait to have tag completion in the interface. This will be
nice.

One thing we'll still have to think about is how to remove the "virtual
tags" from the completion list, (once we have virtual tags in the
configuration file---that is, tags applied automatically based on search
specifications).

The place we'd want to remove these from the completion list is when
adding/removing a tag---it should be illegal to add/remove virtual tags
since they will be maintained by the system according to the search
specifications.

Of course, when searching/filtering by tag, the completion list should
include all tags, whether manual or virtual.

So, what we're going to need for that is something like "notmuch config"
that allows the interface to query the configuration.

But that's all down the road. Let's get that tag completion working!

-Carl