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