[PATCH 1/2] notmuch: Support for notmuch_database_get_tags

[PATCH 1/2] notmuch: Support for notmuch_database_get_tags

[Jan Janak]

This patch adds a new function called notmuch_database_get_tags which
can be used to obtain a list of all tags defined in the database (that
is, the list all tags from all messages). The function produces an
alphabetically sorted list.

To add support for the new function, we rip the guts off of
notmuch_message_get_tags and put them in a new generic function
called _notmuch_convert_tags. The generic function takes a TermIterator
as argument and produces a notmuch_tags_t list of tags.

Function notmuch_message_get_tags is then reimplemented to call the
generic function with message->doc.termlist_begin() as argument.

Similarly, we implement notmuch_message_database_tags, the function
calls the generic function with db->xapian_db->allterms_begin() as
argument.

Finally, notmuch_database_get_tags is exported through lib/notmuch.h

Signed-off-by: Jan Janak <jan@ryngle.com>
---
 lib/database.cc |   48 ++++++++++++++++++++++++++++++++++++++++++++++++
 lib/message.cc  |   38 ++++++--------------------------------
 lib/notmuch.h   |    4 ++++
 3 files changed, 58 insertions(+), 32 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index 4998fc9..b1c15c3 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -983,3 +983,51 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
 
     return ret;
 }
+
+notmuch_tags_t *
+_notmuch_convert_tags (void* ctx, Xapian::TermIterator i);
+
+/* Converts tags from the format used in Xapian to a list in
+   notmuch_tags_t. */
+notmuch_tags_t *
+_notmuch_convert_tags (void* ctx, Xapian::TermIterator i)
+{
+    const char *prefix = _find_prefix ("tag");
+    notmuch_tags_t *tags;
+    std::string tag;
+
+    /* Currently this iteration is written with the assumption that
+     * "tag" has a single-character prefix. */
+    assert (strlen (prefix) == 1);
+
+    tags = _notmuch_tags_create (ctx);
+    if (unlikely (tags == NULL))
+	return NULL;
+
+    i.skip_to (prefix);
+
+    while (1) {
+	tag = *i;
+
+	if (tag.empty () || tag[0] != *prefix)
+	    break;
+
+	_notmuch_tags_add_tag (tags, tag.c_str () + 1);
+
+	i++;
+    }
+
+    _notmuch_tags_prepare_iterator (tags);
+
+    return tags;
+}
+
+/*
+ * Returns a list of all tags defined in a notmuch database. The resulting
+ * list is sorted alphabetically.
+ */
+notmuch_tags_t *
+notmuch_database_get_tags (notmuch_database_t *db)
+{
+	return _notmuch_convert_tags(db, db->xapian_db->allterms_begin());
+}
diff --git a/lib/message.cc b/lib/message.cc
index 9488fb6..af23bb2 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -41,6 +41,9 @@ struct _notmuch_message {
     Xapian::Document doc;
 };
 
+extern notmuch_tags_t *
+_notmuch_convert_tags (void* ctx, Xapian::TermIterator i);
+
 /* "128 bits of thread-id ought to be enough for anybody" */
 #define NOTMUCH_THREAD_ID_BITS	 128
 #define NOTMUCH_THREAD_ID_DIGITS (NOTMUCH_THREAD_ID_BITS / 4)
@@ -445,43 +448,14 @@ notmuch_message_get_date (notmuch_message_t *message)
     return Xapian::sortable_unserialise (value);
 }
 
+
 notmuch_tags_t *
 notmuch_message_get_tags (notmuch_message_t *message)
 {
-    const char *prefix = _find_prefix ("tag");
-    Xapian::TermIterator i, end;
-    notmuch_tags_t *tags;
-    std::string tag;
-
-    /* Currently this iteration is written with the assumption that
-     * "tag" has a single-character prefix. */
-    assert (strlen (prefix) == 1);
-
-    tags = _notmuch_tags_create (message);
-    if (unlikely (tags == NULL))
-	return NULL;
-
-    i = message->doc.termlist_begin ();
-    end = message->doc.termlist_end ();
-
-    i.skip_to (prefix);
-
-    while (1) {
-	tag = *i;
-
-	if (tag.empty () || tag[0] != *prefix)
-	    break;
-
-	_notmuch_tags_add_tag (tags, tag.c_str () + 1);
-
-	i++;
-    }
-
-    _notmuch_tags_prepare_iterator (tags);
-
-    return tags;
+	return _notmuch_convert_tags(message, message->doc.termlist_begin());
 }
 
+
 void
 _notmuch_message_set_date (notmuch_message_t *message,
 			   const char *date)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index cc713a3..1edcfd6 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -271,6 +271,10 @@ notmuch_message_t *
 notmuch_database_find_message (notmuch_database_t *database,
 			       const char *message_id);
 
+notmuch_tags_t *
+notmuch_database_get_tags (notmuch_database_t *database);
+
+
 /* Create a new query for 'database'.
  *
  * Here, 'database' should be an open database, (see
-- 
1.6.3.3

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

[Jan Janak]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4604 bytes --]

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 <jan@ryngle.com>
---
 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 0000000..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 <cworth@cworth.org>
+ *          Jan Janak <jan@ryngle.com>
+ */
+
+#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,
+	  "<what>",
+	  "\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,
       "[<command>]",
       "\t\tThis message, or more detailed help for the named command.",
-- 
1.6.3.3

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

[Jan Janak]

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 <jan@ryngle.com> 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 <jan@ryngle.com>
> ---
>  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 0000000..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 <cworth@cworth.org>
> + *          Jan Janak <jan@ryngle.com>
> + */
> +
> +#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,
> +         "<what>",
> +         "\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,
>       "[<command>]",
>       "\t\tThis message, or more detailed help for the named command.",
> --
> 1.6.3.3
>
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
>

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

[Carl Worth]

On Thu, 19 Nov 2009 12:52:49 +0100, Jan Janak <jan@ryngle.com> 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

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

[Jan Janak]

On Thu, Nov 19, 2009 at 3:41 PM, Carl Worth <cworth@cworth.org> wrote:
> On Thu, 19 Nov 2009 12:52:49 +0100, Jan Janak <jan@ryngle.com> 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

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

[Bdale Garbee]

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

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

[Carl Worth]

On Thu, 19 Nov 2009 10:59:13 -0700, Bdale Garbee <bdale@gag.com> 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

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

[Jan Janak]

On Thu, Nov 19, 2009 at 3:41 PM, Carl Worth <cworth@cworth.org> wrote:
> On Thu, 19 Nov 2009 12:52:49 +0100, Jan Janak <jan@ryngle.com> 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

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

[Carl Worth]

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

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

[Jed Brown]

On Sun, 22 Nov 2009 00:07:57 +0100, Carl Worth <cworth@cworth.org> 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

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

[Bart Trojanowski]

* Carl Worth <cworth@cworth.org> [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/

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

[Carl Worth]

On Sun, 22 Nov 2009 00:21:19 +0100, Jed Brown <jed@59A2.org> wrote:
> On Sun, 22 Nov 2009 00:07:57 +0100, Carl Worth <cworth@cworth.org> 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