[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Sun, 22 Nov 2009 00:21:19 +0100, Jed Brown wrote: > On Sun, 22 Nov 2009 00:07:57 +0100, Carl Worth wrote: > > 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). > > Do these need to be real tags? Would it be sufficient for them to just > be aliases for search patterns? I think I would prefer the latter > because I could modify the pattern and not have to rewrite tags to the > whole database. Maybe real tags are needed to optimize expensive > patterns, but I wouldn't think the user needs to know about that. They are conceptually just aliases for search patterns, yes. But when I'm working with my mail I think I want them be accessible in an identical way to tags I apply manually. That is I want to be able to search for "tag:foo" and filter the current search view on the "bar" tag without having to remember to distinguish as a users whether "foo" or "bar" is a tag or an "aliased search term". As for your concerns, tag updates are going to be made really fast, (we just *have* to fix that bug, and soon), so I don't think there's going to be any problem with updating these rules and having to update the state in the database. -Carl
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Sun, 22 Nov 2009 00:07:57 +0100, Carl Worth wrote: > 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). Do these need to be real tags? Would it be sufficient for them to just be aliases for search patterns? I think I would prefer the latter because I could modify the pattern and not have to rewrite tags to the whole database. Maybe real tags are needed to optimize expensive patterns, but I wouldn't think the user needs to know about that. Jed
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Sat, 21 Nov 2009 22:07:14 +0100, Jan Janak 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
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
* Carl Worth [091121 18:08]: > 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. I too prefer this option. It keeps the interface and code simpler. Moreover, it might also eliminate the need for 'notmuch count'. Simply pass --count-only to the search command. -Bart -- WebSig: http://www.jukie.net/~bart/sig/
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Thu, Nov 19, 2009 at 3:41 PM, Carl Worth wrote: > On Thu, 19 Nov 2009 12:52:49 +0100, Jan Janak wrote: >> I implemented a new notmuch command that can be used to list all tags >> present in the database: > > Ah, very very interesting! I'd been planning on doing something like > this soon. And I was just thinking of "notmuch tags" as the command > line. What other ideas do you have in mind for "notmuch list" ? > > One way we could possibly do "notmuch tags" is to have it accept search > terms and then return the list of all tags from the matched messages. > Then of course we'd need a syntax for a search term to match all > messages, (which we want in any case). > >> The main reason why I implemented this is because I am also working on >> adding the tag completion feature to the Emacs mode. This is very >> useful if you have a large collection of tags--it can save you some >> typing and, perhaps more importantly, it minimizes the risk of having >> typos in tag names. I'll send a patch for that later too. > > That will be a very nice feature to have, yes. > > The other reason I've wanted this is have something like a "folder view" > that would show a list of tags and a number of messages with each tag, > (or a number of messages with that tag and the inbox tag). > > I know that Keith said he'd prefer to use a view like that as his > primary way of reading mail. > > Actual review of the patch later. Carl and others, 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. 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. -- Jan
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Thu, 19 Nov 2009 10:59:13 -0700, Bdale Garbee wrote: > I've been pondering approaches to prioritizing the pool of unread > messages. Most of my thinking so far is along the lines of the ability > to automatically apply tags to new messages on various criteria combined > with the ability to manipulate the order in which tags are presented in > a view like what you're describing. Yes. There's definitely a lot of room for experimenting here to figure out how to make things work. > For better or worse, with about 45k messages hitting my inbox per year > *after* most of the list traffic gets peeled off and fed to a private > NNTP server, it's not about reading all of my email any more... it's > about finding and reading the stuff that actually matters *to me*. I totally understand that, (even if I've got an order of magnitude less of non-list mail coming to me). And I hope we can figure out how to support that mode well. > Can't tell you how excited I am about what's happening here! Thanks so much. And it's a pleasure to have you as part of the community here. I'll look forward to your input. -Carl
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Thu, Nov 19, 2009 at 3:41 PM, Carl Worth wrote: > On Thu, 19 Nov 2009 12:52:49 +0100, Jan Janak wrote: >> I implemented a new notmuch command that can be used to list all tags >> present in the database: > > Ah, very very interesting! I'd been planning on doing something like > this soon. And I was just thinking of "notmuch tags" as the command > line. What other ideas do you have in mind for "notmuch list" ? Yes, I considered "notmuch tags" too, but then I realized that we already have "notmuch tag" and I was worried that having both tag and tags as commands could be confusing. I was also thinking that "notmuch list" could be extended to list other terms than just tags, but I currently have no use-case for that. In any case, this is just an initial proposal, I can change it to use some other command name if you prefer that. > One way we could possibly do "notmuch tags" is to have it accept search > terms and then return the list of all tags from the matched messages. > Then of course we'd need a syntax for a search term to match all > messages, (which we want in any case). That sounds like a good idea. If the user does not provide any search terms then we could return all tags from the database like we do now. If there is a search term then we could iterate through all the messages that match it, collect their tags, sort them and present to the user. >> The main reason why I implemented this is because I am also working on >> adding the tag completion feature to the Emacs mode. This is very >> useful if you have a large collection of tags--it can save you some >> typing and, perhaps more importantly, it minimizes the risk of having >> typos in tag names. I'll send a patch for that later too. > > That will be a very nice feature to have, yes. > > The other reason I've wanted this is have something like a "folder view" > that would show a list of tags and a number of messages with each tag, > (or a number of messages with that tag and the inbox tag). Yeah, I would want that too :-). I've already looked into this and it seems like it should be easy to implement. At least it seems to be easy to get the numbers from Xapian. So we would just need to come up with a format for the list of tags with message counts, read it into emacs and present in a buffer. -- Jan
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Thu, 19 Nov 2009 12:52:49 +0100, Jan Janak wrote: > I implemented a new notmuch command that can be used to list all tags > present in the database: Ah, very very interesting! I'd been planning on doing something like this soon. And I was just thinking of "notmuch tags" as the command line. What other ideas do you have in mind for "notmuch list" ? One way we could possibly do "notmuch tags" is to have it accept search terms and then return the list of all tags from the matched messages. Then of course we'd need a syntax for a search term to match all messages, (which we want in any case). > The main reason why I implemented this is because I am also working on > adding the tag completion feature to the Emacs mode. This is very > useful if you have a large collection of tags--it can save you some > typing and, perhaps more importantly, it minimizes the risk of having > typos in tag names. I'll send a patch for that later too. That will be a very nice feature to have, yes. The other reason I've wanted this is have something like a "folder view" that would show a list of tags and a number of messages with each tag, (or a number of messages with that tag and the inbox tag). I know that Keith said he'd prefer to use a view like that as his primary way of reading mail. Actual review of the patch later. -Carl
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
Carl and others,
I implemented a new notmuch command that can be used to list all tags
present in the database:
$ notmuch list tags
If you run this, you'll get an alphabetically sorted list of all
tags--one tag per line.
The main reason why I implemented this is because I am also working on
adding the tag completion feature to the Emacs mode. This is very
useful if you have a large collection of tags--it can save you some
typing and, perhaps more importantly, it minimizes the risk of having
typos in tag names. I'll send a patch for that later too.
Let me know what do you think.
-- Jan
On Thu, Nov 19, 2009 at 12:34 PM, Jan Janak wrote:
> Here we create a new notmuch command called list. The purpose of the
> command is to produce various lists from the notmuch database.
>
> At the moment we support only one command, notmuch list tags. This
> command creates a list of all tags found in the database.
>
> Signed-off-by: Jan Janak
> ---
> ?Makefile.local ? | ? ?1 +
> ?notmuch-client.h | ? ?3 ++
> ?notmuch-list.c ? | ? 98
> ++
> ?notmuch.c ? ? ? ?| ? 10 +
> ?4 files changed, 112 insertions(+), 0 deletions(-)
> ?create mode 100644 notmuch-list.c
>
> diff --git a/Makefile.local b/Makefile.local
> index 27e42ba..fb6d5c3 100644
> --- a/Makefile.local
> +++ b/Makefile.local
> @@ -12,6 +12,7 @@ notmuch_client_srcs = ? ? ? ? \
> ? ? ? ?notmuch-show.c ? ? ? ? ?\
> ? ? ? ?notmuch-tag.c ? ? ? ? ? \
> ? ? ? ?notmuch-time.c ? ? ? ? ?\
> + ? ?notmuch-list.c ? ? ?\
> ? ? ? ?gmime-filter-reply.c ? ?\
> ? ? ? ?query-string.c ? ? ? ? ?\
> ? ? ? ?show-message.c
> diff --git a/notmuch-client.h b/notmuch-client.h
> index b65aa77..ae876b5 100644
> --- a/notmuch-client.h
> +++ b/notmuch-client.h
> @@ -114,6 +114,9 @@ notmuch_show_command (void *ctx, int argc, char *argv[]);
> ?int
> ?notmuch_tag_command (void *ctx, int argc, char *argv[]);
>
> +int
> +notmuch_list_command (void *ctx, int argc, char *argv[]);
> +
> ?const char *
> ?notmuch_time_relative_date (const void *ctx, time_t then);
>
> diff --git a/notmuch-list.c b/notmuch-list.c
> new file mode 100644
> index 000..fe71108
> --- /dev/null
> +++ b/notmuch-list.c
> @@ -0,0 +1,98 @@
> +/* notmuch - Not much of an email program, (just index and search)
> + *
> + * Copyright ? 2009 Carl Worth
> + * Copyright ? 2009 Jan Janak
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. ?If not, see http://www.gnu.org/licenses/ .
> + *
> + * Authors: Carl Worth
> + * ? ? ? ? ?Jan Janak
> + */
> +
> +#include "notmuch-client.h"
> +
> +enum list_cmd {
> + ? ? ? LIST_TAGS
> +};
> +
> +
> +static int
> +list_all_tags(notmuch_database_t* db)
> +{
> + ? ? ? notmuch_tags_t* tags;
> + ? ? ? const char* t;
> +
> + ? ? ? if ((tags = notmuch_database_get_tags(db)) == NULL) {
> + ? ? ? ? ? ? ? fprintf(stderr, "Error while obtaining tags from the
> database.\n");
> + ? ? ? ? ? ? ? return 1;
> + ? ? ? }
> +
> + ? ? ? while((t = notmuch_tags_get(tags))) {
> + ? ? ? ? ? ? ? printf("%s\n", t);
> + ? ? ? ? ? ? ? notmuch_tags_advance(tags);
> + ? ? ? }
> +
> + ? ? ? notmuch_tags_destroy(tags);
> + ? ? ? return 0;
> +}
> +
> +int
> +notmuch_list_command (void *ctx, int argc, char *argv[])
> +{
> + ? ?notmuch_config_t *config;
> + ? ?notmuch_database_t *db;
> + ? ? ? enum list_cmd cmd;
> +
> + ? ? ? config = NULL;
> + ? ? ? db = NULL;
> +
> + ? ? ? if (argc < 1) {
> + ? ? ? ? ? ? ? fprintf(stderr, "Error: notmuch list requires at least one
> parameter.\n");
> + ? ? ? ? ? ? ? fprintf(stderr, "(See notmuch help list)\n");
> + ? ? ? ? ? ? ? goto error;
> + ? ? ? }
> +
> + ? ? ? if (!strcmp(argv[0], "tags")) {
> + ? ? ? ? ? ? ? cmd = LIST_TAGS;
> + ? ? ? } else {
> + ? ? ? ? ? ? ? fprintf(stderr, "Sub-command '%s' not supported.\n", argv[0]);
> + ? ? ? ? ? ? ? goto error;
> + ? ? ? }
> +
> + ? ?if ((config = notmuch_config_open (ctx, NULL, NULL)) == NULL) {
> + ? ? ? ? ? ? ? goto error;
> + ? ? ? }
> +
> + ? ?db = notmuch_database_open (notmuch_config_get_database_path (config));
> + ? ?if (db == NULL) {
> + ? ? ? ? ? ? ? goto error;
> + ? ? ? }
> +
> + ? ? ? switch(cmd) {
> + ? ? ? case LIST_TAGS:
> + ? ? ? ? ? ? ? if (list_all_tags(db) != 0) goto error;
> + ? ? ? ? ? ? ? break;
> +
> + ? ? ? default:
> + ? ? ? ? ? ? ? fprintf(stderr, "Unsupported command: bug in
> notmuch_list_command.\n");
> + ? ? ? ? ? ? ? goto error;
> + ? ? ? }
> +
> + ? ?notmuch_database
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
Here we create a new notmuch command called list. The purpose of the
command is to produce various lists from the notmuch database.
At the moment we support only one command, notmuch list tags. This
command creates a list of all tags found in the database.
Signed-off-by: Jan Janak
---
Makefile.local |1 +
notmuch-client.h |3 ++
notmuch-list.c | 98 ++
notmuch.c| 10 +
4 files changed, 112 insertions(+), 0 deletions(-)
create mode 100644 notmuch-list.c
diff --git a/Makefile.local b/Makefile.local
index 27e42ba..fb6d5c3 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -12,6 +12,7 @@ notmuch_client_srcs = \
notmuch-show.c \
notmuch-tag.c \
notmuch-time.c \
+notmuch-list.c \
gmime-filter-reply.c\
query-string.c \
show-message.c
diff --git a/notmuch-client.h b/notmuch-client.h
index b65aa77..ae876b5 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -114,6 +114,9 @@ notmuch_show_command (void *ctx, int argc, char *argv[]);
int
notmuch_tag_command (void *ctx, int argc, char *argv[]);
+int
+notmuch_list_command (void *ctx, int argc, char *argv[]);
+
const char *
notmuch_time_relative_date (const void *ctx, time_t then);
diff --git a/notmuch-list.c b/notmuch-list.c
new file mode 100644
index 000..fe71108
--- /dev/null
+++ b/notmuch-list.c
@@ -0,0 +1,98 @@
+/* notmuch - Not much of an email program, (just index and search)
+ *
+ * Copyright ?? 2009 Carl Worth
+ * Copyright ?? 2009 Jan Janak
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/ .
+ *
+ * Authors: Carl Worth
+ * Jan Janak
+ */
+
+#include "notmuch-client.h"
+
+enum list_cmd {
+ LIST_TAGS
+};
+
+
+static int
+list_all_tags(notmuch_database_t* db)
+{
+ notmuch_tags_t* tags;
+ const char* t;
+
+ if ((tags = notmuch_database_get_tags(db)) == NULL) {
+ fprintf(stderr, "Error while obtaining tags from the
database.\n");
+ return 1;
+ }
+
+ while((t = notmuch_tags_get(tags))) {
+ printf("%s\n", t);
+ notmuch_tags_advance(tags);
+ }
+
+ notmuch_tags_destroy(tags);
+ return 0;
+}
+
+int
+notmuch_list_command (void *ctx, int argc, char *argv[])
+{
+notmuch_config_t *config;
+notmuch_database_t *db;
+ enum list_cmd cmd;
+
+ config = NULL;
+ db = NULL;
+
+ if (argc < 1) {
+ fprintf(stderr, "Error: notmuch list requires at least one
parameter.\n");
+ fprintf(stderr, "(See notmuch help list)\n");
+ goto error;
+ }
+
+ if (!strcmp(argv[0], "tags")) {
+ cmd = LIST_TAGS;
+ } else {
+ fprintf(stderr, "Sub-command '%s' not supported.\n", argv[0]);
+ goto error;
+ }
+
+if ((config = notmuch_config_open (ctx, NULL, NULL)) == NULL) {
+ goto error;
+ }
+
+db = notmuch_database_open (notmuch_config_get_database_path (config));
+if (db == NULL) {
+ goto error;
+ }
+
+ switch(cmd) {
+ case LIST_TAGS:
+ if (list_all_tags(db) != 0) goto error;
+ break;
+
+ default:
+ fprintf(stderr, "Unsupported command: bug in
notmuch_list_command.\n");
+ goto error;
+ }
+
+notmuch_database_close (db);
+return 0;
+
+error:
+ if (db) notmuch_database_close(db);
+ return 1;
+}
diff --git a/notmuch.c b/notmuch.c
index 5cc8e4c..1baa22d 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -230,6 +230,16 @@ command_t commands[] = {
"\t\tSo if you've previously been using sup for mail, then the\n"
"\t\t\"notmuch restore\" command provides you a way to import\n"
"\t\tall of your tags (or labels as sup calls them)." },
+ { "list", notmuch_list_command,
+ "",
+ "\t\tShow additional information about the database.",
+ "\t\tThe following sub-commands are supported:"
+ "\n\n"
+ "\t\ttags\n"
+ "\n"
+ "\t\t\tGenerate a list of all tags available in the database.\n"
+ "\t\t\tThe list will be sorted alphabetically."
+ },
{ "help", notmuch_help_command,
"[]",
"\t\tThis message, or more detailed help
[notmuch] [PATCH 2/2] notmuch list: A new command to produce various lists.
On Thu, 2009-11-19 at 15:41 +0100, Carl Worth wrote: > The other reason I've wanted this is have something like a "folder view" > that would show a list of tags and a number of messages with each tag, > (or a number of messages with that tag and the inbox tag). > > I know that Keith said he'd prefer to use a view like that as his > primary way of reading mail. Yes. I've been pondering approaches to prioritizing the pool of unread messages. Most of my thinking so far is along the lines of the ability to automatically apply tags to new messages on various criteria combined with the ability to manipulate the order in which tags are presented in a view like what you're describing. For better or worse, with about 45k messages hitting my inbox per year *after* most of the list traffic gets peeled off and fed to a private NNTP server, it's not about reading all of my email any more... it's about finding and reading the stuff that actually matters *to me*. Can't tell you how excited I am about what's happening here! Bdale
