[notmuch] [RFC PATCH -V2] notmuch: Add support for multiple maildirs

2009-11-22 Thread Aneesh Kumar K.V
This patch separate database path and maildir paths.
It also adds support for multiple maildir paths which
is represented by comma separated values. You need
to have in ~/.notmuch-config

[maildirs]
path=path1,path2

Signed-off-by: Aneesh Kumar K.V 
---
 notmuch-client.h |   12 
 notmuch-config.c |   54 ++
 notmuch-new.c|   24 +---
 notmuch-setup.c  |   37 +++--
 4 files changed, 122 insertions(+), 5 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index ea77686..f2fc19f 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -83,6 +83,11 @@ typedef struct {
 add_files_callback_t callback;
 } add_files_state_t;

+struct count_ele {
+   int count;
+   char ele[0];
+};
+
 static inline void
 chomp_newline (char *str)
 {
@@ -182,4 +187,11 @@ notmuch_config_set_user_other_email (notmuch_config_t 
*config,
 notmuch_bool_t
 debugger_is_active (void);

+const struct count_ele *
+notmuch_config_get_maildirs (notmuch_config_t *config);
+
+void
+notmuch_config_set_maildirs (notmuch_config_t *config,
+   const char *maildirs);
+
 #endif
diff --git a/notmuch-config.c b/notmuch-config.c
index aaa0372..330da48 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -62,6 +62,7 @@ struct _notmuch_config {
 char *user_primary_email;
 char **user_other_email;
 size_t user_other_email_length;
+struct count_ele *maildirs;
 };

 static int
@@ -345,6 +346,59 @@ notmuch_config_set_database_path (notmuch_config_t *config,
 config->database_path = NULL;
 }

+const struct count_ele *
+notmuch_config_get_maildirs (notmuch_config_t *config)
+{
+   int size;
+   char *cur_ptr;
+   char *dirs, *token, *saveptr;
+   struct count_ele *maildirs = NULL;
+   if (config->maildirs == NULL) {
+dirs = g_key_file_get_string (config->key_file,
+"maildirs", "path", NULL);
+   if (dirs) {
+   size = sizeof(struct count_ele) + strlen(dirs) + 1;
+   /* comma separated paths */
+   maildirs = (struct count_ele *)malloc(size);
+   maildirs->count = 0;
+   cur_ptr = maildirs->ele;
+   token = strtok_r(dirs, ",", );
+   if (token == NULL) {
+   /* only one element */
+   strcpy(maildirs->ele, dirs);
+   maildirs->count = 1;
+   free(dirs);
+   config->maildirs = maildirs;
+   return maildirs;
+   }
+   strcpy(maildirs->ele, token);
+   maildirs->count++;
+   cur_ptr += strlen(token) + 1;
+   while ((token = strtok_r(NULL, ",", ))) {
+   strcpy(cur_ptr, token);
+   maildirs->count++;
+   cur_ptr += strlen(token) + 1;
+   }
+   free (dirs);
+   }
+   config->maildirs = maildirs;
+   }
+   return config->maildirs;
+
+
+}
+
+void
+notmuch_config_set_maildirs (notmuch_config_t *config,
+ const char *maildirs)
+{
+g_key_file_set_string (config->key_file,
+  "maildirs", "path", maildirs);
+
+free (config->maildirs);
+config->maildirs = NULL;
+}
+
 const char *
 notmuch_config_get_user_name (notmuch_config_t *config)
 {
diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..1a9406b 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -385,14 +385,16 @@ notmuch_new_command (void *ctx,
 {
 notmuch_config_t *config;
 notmuch_database_t *notmuch;
+const struct count_ele *maildirs;
 add_files_state_t add_files_state;
 double elapsed;
 struct timeval tv_now;
-int ret = 0;
+int ret = 0, maildirs_count;
 struct stat st;
 const char *db_path;
 char *dot_notmuch_path;
 struct sigaction action;
+const char *maildir_path;

 /* Setup our handler for SIGINT */
 memset (, 0, sizeof (struct sigaction));
@@ -406,6 +408,9 @@ notmuch_new_command (void *ctx,
return 1;

 db_path = notmuch_config_get_database_path (config);
+maildirs = notmuch_config_get_maildirs (config);
+if (maildirs == NULL)
+   return 1;

 dot_notmuch_path = talloc_asprintf (ctx, "%s/%s", db_path, ".notmuch");

@@ -413,7 +418,13 @@ notmuch_new_command (void *ctx,
int count;

count = 0;
-   count_files (db_path, );
+   maildirs_count = maildirs->count;
+   maildir_path   = maildirs->ele;
+   while (maildirs_count) {
+   count_files (maildir_path, );
+   maildir_path += 

[notmuch] interesting project!

2009-11-22 Thread Carl Worth
On Sun, 22 Nov 2009 14:23:10 +0200, Dirk-Jan C. Binnema  wrote:
> A small question: it seems that notmuch is avoiding the use of GLib directly
> (of course, it depend on it anyway through GMime); is this because of
> OOM-handling? It'd be nice if GLib could be used, it would make some things
> quite a bit easier.

It's true that I don't like the OOM handling in glib. I also think that
glib tries to be too many different things at the same time. And
finally, having some talloc-friendly data structures (like a hash-table)
would be really nice.

In the meantime, as you say, we're already linking with glib because of
GMime, so there's really no reason not to call functions that are there
and that do what we want. What kinds of things were you thinking of that
would be easier with glib?

-Carl


[notmuch] [PATCH -v2] notmuch.el: Add face support to search and show mode

2009-11-22 Thread Carl Worth
On Sun, 22 Nov 2009 17:51:06 +0530, "Aneesh Kumar K.V"  wrote:
> > It's interesting to be able to highlight specific tags like this. But I
> > think that first I'd like to have a single 'notmuch-tag face to make it
> > easier to see all the tag names, since they're hard to see among the
> > subject. And then maybe after that have s 'notmuch-tag-important-face or
> > something. I'm guessing that just that much would cover most people's
> > needs, before needing to choose custom colors for each tag name.
> 
> The default search pattern for notmuch is inbox and unread right. So adding
> both of them to the notmuch-tag-face-alist should color the tags
> properly.

Well, actually the default search pattern for notmuch is just "inbox".

But it's really about *all* the tags I have on the messages. I would
like all of my tags to stand out from the subject line, (and I don't
want to keep adjusting notmuch-tag-face-alist every time I add a new
tag).

I'd prefer instead to just be able to choose a color that would
highlight everyhing between the final set of parentheses in the search
results.

> One of the easy part with emacs is we can use customize-face and select 
> notmuch-show-subject-face to select what ever suites your configuration.
> For me with black background i found yellow with bold to be nice.

OK. I'll experiment and look for a reasonable color for a white
background.

-Carl


[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-22 Thread Dirk-Jan C. Binnema
Hi Michiel,

> "MB" == Michiel Buddingh'  writes:

MB> Dirk-Jan C. Binnema  wrote:
Michiel> +
Michiel> +static void
Michiel> +derive_tags_from_maildir_flags (notmuch_message_t 
Michiel> *message, const char *
Michiel> path)
>> 
>> I see you don't handle the "N" -- is that deliberate? Also, a 
>> minor addition may to also allow for '!' instead of ':' as a 
>> separator, as that's the semi-official way to use Maildirs on 
>> (V)FAT filesystems (which don't allow for colons in filenames).

MB> Not deliberate.  Simply unaware of the "N" flag, nor aware of 
MB> practices for storing Maildirs on (V)FAT.

Ah, you are right. In my code,
 http://gitorious.org/mu/mainline/blobs/master/msg/mu-msg-flags.c
I handled it because apparently some programs where using that. But I guess
it's better to stick to DJB's Maildir spec for now...

Regarding the VFAT-limitations, see eg. the Note in:
  http://docs.python.org/lib/mailbox-maildir.html
anyway, a minor point.


Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema  Helsinki, Finland
e:djcb at djcbsoftware.nl   w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C


[notmuch] [PATCH] ANSI escapes in "new" only when output is a tty

2009-11-22 Thread Keith Packard
On Mon, 23 Nov 2009 06:12:09 +0100, Carl Worth  wrote:

> So that's totally broken and we should come up with a way to fix it.

Tracking directory mtime instead of just looking at the read-only bit
would let us skip directories that haven't seen any change in content.

Tracking directory contents would let us easily detect name changes
(add/remove/rename).

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/36b83be5/attachment.pgp>


[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags

2009-11-22 Thread Keith Packard
On Mon, 23 Nov 2009 07:31:04 +0100, Carl Worth  wrote:

> OK. You win. That looks pretty good to me.

So we need to do the 'mark all that have been seen read' change, then we
can do the rest of this switch. Not sure how to make that work, as we
need to know what has been displayed, and you can display bits of the
window in lots of different ways (even using the mouse!)

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/06b91513/attachment.pgp>


[notmuch] notmuch 'index' mode.

2009-11-22 Thread Keith Packard
On Mon, 23 Nov 2009 07:06:06 +0100, Carl Worth  wrote:
> On Fri, 20 Nov 2009 23:35:29 -0800, Keith Packard  
> wrote:
> > I posted a patch adding an 'index' mode to notmuch and though I'd
> > explain my idea. Most mail systems provide a 'folder view' mode which
> > displays the set of folders and a count of messages in each folder. I
> > used this myself as the first sort of which messages I want to read.
> 
> I've just pushed this set of patches out now.
> 
> I like it quite a bit. Here are some thoughts:
> 
>   * The mode documentation really needs to walk the user through how to
> setup a custom set of folders.

You can use the standard emacs customization interface, although it's
not exactly well documented there. Additional docs are clearly
indicated.

>   * It's not opening my "to-me" folder for some reason. (I thought it
> was the '-' at first, but "xorg-board" is working fine). I can debug
> this later.

It shouldn't work on xorg-board either -- it just skips forward one
'word' and assumes it's gotten the folder name. Lame programming, I
know. Should be easy to fix.

>   * The presentation is impressively spartan[*]. :-)

What more do you need? Pretty fonts? Icons? A pony?

> If we spruce this up a bit, I think we'll want to make this the default
> view of "M-x notmuch".

Let's figure out what we want it to look like then. I suggest that we
use some font tricks (bold/regular) to highlight folders with
un-archived mail. I'd also like to be able to create a hierarchy.

> Oh, and instead of just documenting how to set a variable in .emacs we
> should just provide commands to add/remove folders.

That seems doable; it really only takes two text fields after all.

> I think the number of threads matching the search is the only
> interesting number actually. Otherwise, you just end up printing a bunch
> of big numbers that the user doesn't need for anything.

Threads or messages? Threads are more expensive to compute, and when the
number is zero, it means the same thing. But, it is surprising to see a
huge number in the folder view and then get only a handful of threads in
the search view. Perhaps if the count is small enough we can go through
and actually figure out how many threads are involved.

> So maybe the user configures a search template to use for each automatic
> tag or so?

Ack! I suggest that the simpler approach of just duplicating the search
field will work fine in practice. Otherwise, you're talking miles of UI
goo, and constantly confused users. Really, you can use emacs to edit
these things if you get too many.

> It's only when I get my search results down below a particular
> threshold that I decide I want to read everything linearly.

I have started doing this sometimes too. But, I still skim things like
the mesa list and only read a few by clicking through and 'x'ing back.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/9db66e2b/attachment-0001.pgp>


[notmuch] Catching up unread messages

2009-11-22 Thread Jed Brown
On Sun, 22 Nov 2009 22:48:52 +0100, Tassilo Horn  
wrote:
> Ok, so new the question: I indexed all my 63.000 mails, and because it
> was a first-time indexing, all my mail now has the tags inbox and
> unread.  Of course, I don't want to SPC through all threads (using the
> great emacs interface) to remove the unread status.  So is there some
> catchup command, which marks all messages in the buffer as read?

With this patch

  <1258920736-14205-1-git-send-email-jed at 59A2.org>

you would do

  * -inbox

or

  * -inbox -unread

On the command line, you can clear it with

$ notmuch tag -inbox tag:inbox

> BTW, what's the intention of the inbox tag?  When I've read a thread,
> both inbox as well as unread disappear, so I don't get the difference
> between them.

That is because SPC is bound to
notmuch-show-advance-marking-read-and-archiving which removes both tags.
The idea is that you can clear your inbox while retaining unread status,
or leave something important in your inbox even though you have read it.

Jed


[notmuch] Catching up unread messages

2009-11-22 Thread Tassilo Horn
Hi!

I got notmuch running, and it's absolutely incredible.  It's so damn
fast and the results are very good.  So thanks a lot for creating this
nice piece of software. :-)

Ok, so new the question: I indexed all my 63.000 mails, and because it
was a first-time indexing, all my mail now has the tags inbox and
unread.  Of course, I don't want to SPC through all threads (using the
great emacs interface) to remove the unread status.  So is there some
catchup command, which marks all messages in the buffer as read?

BTW, what's the intention of the inbox tag?  When I've read a thread,
both inbox as well as unread disappear, so I don't get the difference
between them.

Bye,
Tassilo


[notmuch] [PATCH] fix compiler warnings

2009-11-22 Thread Jeffrey Ollie
On Sun, Nov 22, 2009 at 9:22 PM, Carl Worth  wrote:
> On Sun, 22 Nov 2009 17:11:03 +0200, Dirk-Jan C. Binnema  gmail.com> wrote:
>>
>> - ? ?write(2, msg, sizeof(msg)-1);
>> + ? ?if (write(2, msg, sizeof(msg)-1) < 0) {
>> + ? ? ? ? /* ignore...*/
>> + ? ?}
>
> I don't like the gratuitous conditional here. It clutters the code and
> make is less clear. If we're just trying to squelch a warning about an
> unused return value from a function, then I think I'd rather see:
>
> ? ? ? ?ssize_t ignored;
>
> ? ? ? ?ignored = write (2, msg, sizeof (msg) - 1);

Isn't the usual method for ignoring return values casting to void?

(void) write (2, msg, sizeof (msg) - 1);

-- 
Jeff Ollie


[notmuch] [RFC] Precedence of OR and AND

2009-11-22 Thread Jed Brown
On Sun, 22 Nov 2009 16:36:49 -0500, Bart Trojanowski  wrote:
> Wouldn't this problem be solved by each filter appending a bracketed
> version of your filter?
> 
> You start with tag:inbox and you filter on "term1 or term2" you'd get:
> 
> tag:inbox and (term1 or term2)

Absolutely, and I have this applied locally to notmuch.el, but I didn't
fix notmuch-search-filter-by-tag because that would really need to parse
the expression.  I'm just asking if anyone else thinks binding OR
tighter than AND would be desirable.

Jed


[notmuch] [PATCH] Add SCons build files.

2009-11-22 Thread Jeffrey Ollie
On Sun, Nov 22, 2009 at 9:11 PM, Carl Worth  wrote:
>
> But I'm afraid I really don't want to switch away from just using (GNU)
> make for the actual compilation.
>
> I don't know anything about scons, but if you can use it to write a
> python script that just does the configuration step, (outputting a
> Makefile.config say), then that might be very interesting.

Well, to me, part of the appeal of SCons is that it doesn't generate
Makefiles.This article is a little old, but the first three
sections are a pretty good rundown on the limitations of Make.

http://www.scons.org/wiki/FromMakeToScons

If you really want a tool that generates Makefiles, take a look at
CMake.  Unfortunately, I think CMake tries to do too much with the
Makefiles and they become close to unreadable.  In the attempt I made
to come up with CMake build files, CMake generates at least 3800 lines
of Makefiles (from a starting point of 30 lines of build files).

> Some people
> have recently told me that python would be a much more sane language for
> doing configuration in than shell.

Well, Python is a much more sane language for doing just about
anything as far as I'm concerned. :)

> I don't know if they're right or not, but I'm (somewhat) willing to have
> multiple implementations of the configure script (since there's always
> the option to just skip it and configure Makefile.config manually). But
> I'm definitely not willing to have multiple build systems.

I think that having multiple different configuration systems would be
pretty awful, especially if people make changes to their favourite
configuration system and hope that someone else fixes the others.

> Meanwhile, the only advantage I know for automake is that once it's
> setup, adding a new file to compile is as simple as adding one file to a
> list in the Makefile.am. We've already got notmuch as easy as that with
> just adding a file to a list in Makefile.local.

Once SCons is set up, adding a new file is just a matter of adding the
name of the file to a list as well.  CMake is the same, and I'm sure
that other systems are similar.

> So I'd very much like to continue exploring what we can do with our own
> configuration system, (in whatever language/language(s) make sense).

It would seem to me that we would be re-inventing a lot of the work
already done by other people.

> Thanks for listening,

Same here.

-- 
Jeff Ollie


[notmuch] [RFC] Precedence of OR and AND

2009-11-22 Thread Jed Brown
Currently OR binds more weakly than AND, which is natural in most
contexts, but I think it is rarely desirably for this sort of search.
Suppose I am in looking at my inbox and decide to filter by

  term1 OR term2

Notmuch makes the query

  tag:inbox AND term1 OR term2

which is actually

  (tag:inbox AND term1) OR term2

and not at all what I wanted.  Adding the necessary parentheses to
notmuch-search-filter is trivial but it requires more parentheses for
the overwhelming majority of searches that I think are more common.

Are most searches indeed closer to conjunctive form?

Should OR bind tighter than AND?


Jed


[notmuch] How to index /var/spool/mail with notmuch

2009-11-22 Thread Tassilo Horn
Jed Brown  writes:

Hi Jed,

>>   - I run a local IMAP server (dovecot) and access it using Gnus
>>   - Dovecot stores its mails in /var/spool/mail/ in some one file per
>> message format
>
> How about
>
> $ mkdir -p ~/mail/spool
> $ ln -s /var/spool/mail/$USER/{cur,new,tmp} ~/mail/spool
>
> and point notmuch at ~/mail (or specifically ~/mail/spool).

Brilliant idea.  :-)

Ok, now it's indexing my 63000 mails.  10 minutes to go.

Bye,
Tassilo


[notmuch] How to index /var/spool/mail with notmuch

2009-11-22 Thread Jed Brown
On Sun, 22 Nov 2009 21:24:47 +0100, Tassilo Horn  
wrote:
> Hi all,
> 
> I'd like to try out notmuch.  My mail setup is as follows:
> 
>   - I run a local IMAP server (dovecot) and access it using Gnus
>   - Dovecot stores its mails in /var/spool/mail/ in some one file per
> message format

How about

$ mkdir -p ~/mail/spool
$ ln -s /var/spool/mail/$USER/{cur,new,tmp} ~/mail/spool

and point notmuch at ~/mail (or specifically ~/mail/spool).


Jed


[notmuch] [PATCH] Add SCons build files.

2009-11-22 Thread Ingmar Vanhassel
Personally I'd say we have better things to work on than maintaining
multiple buildsystems for notmuch. Or than resolving possible packaging
bugs originating in the use of different buildsystems.

GNU has a very wide install bas, it's has a low footprint,  and it
happened to be the choice of the initial developers. All of this makes
it the best choice imo.

While I don't want to start a discussion on the merits of various
buildsystems, I'll mention that, in my role as a packager, I'd choose
just about anything over scons.

My 2 cents,
Ingmar

-- 
Exherbo KDE, X.org maintainer


[notmuch] [RFC PATCH] notmuch: Add support for multiple maildirs

2009-11-22 Thread Aneesh Kumar K.V
This patch separate database path and maildir paths.
It also adds support for multiple maildir paths which
is represented by comma separated values. You need
to have in ~/.notmuch-config

[maildirs]
path=path1,path2

Signed-off-by: Aneesh Kumar K.V 
---
 notmuch-client.h |8 
 notmuch-config.c |   43 +++
 notmuch-new.c|   24 +---
 3 files changed, 72 insertions(+), 3 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index ea77686..128fd7f 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -83,6 +83,11 @@ typedef struct {
 add_files_callback_t callback;
 } add_files_state_t;

+struct count_ele {
+   int count;
+   char ele[0];
+};
+
 static inline void
 chomp_newline (char *str)
 {
@@ -182,4 +187,7 @@ notmuch_config_set_user_other_email (notmuch_config_t 
*config,
 notmuch_bool_t
 debugger_is_active (void);

+const struct count_ele *
+notmuch_config_get_maildirs (notmuch_config_t *config);
+
 #endif
diff --git a/notmuch-config.c b/notmuch-config.c
index aaa0372..12b0081 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -62,6 +62,7 @@ struct _notmuch_config {
 char *user_primary_email;
 char **user_other_email;
 size_t user_other_email_length;
+struct count_ele *maildirs;
 };

 static int
@@ -334,6 +335,48 @@ notmuch_config_get_database_path (notmuch_config_t *config)
 return config->database_path;
 }

+const struct count_ele *
+notmuch_config_get_maildirs (notmuch_config_t *config)
+{
+   int size;
+   char *cur_ptr;
+   char *dirs, *token, *saveptr;
+   struct count_ele *maildirs = NULL;
+   if (config->maildirs == NULL) {
+dirs = g_key_file_get_string (config->key_file,
+"maildirs", "path", NULL);
+   if (dirs) {
+   size = sizeof(struct count_ele) + strlen(dirs) + 1;
+   /* comma separated paths */
+   maildirs = (struct count_ele *)malloc(size);
+   maildirs->count = 0;
+   cur_ptr = maildirs->ele;
+   token = strtok_r(dirs, ",", );
+   if (token == NULL) {
+   /* only one element */
+   strcpy(maildirs->ele, dirs);
+   maildirs->count = 1;
+   free(dirs);
+   config->maildirs = maildirs;
+   return maildirs;
+   }
+   strcpy(maildirs->ele, token);
+   maildirs->count++;
+   cur_ptr += strlen(token) + 1;
+   while ((token = strtok_r(NULL, ",", ))) {
+   strcpy(cur_ptr, token);
+   maildirs->count++;
+   cur_ptr += strlen(token) + 1;
+   }
+   free (dirs);
+   }
+   config->maildirs = maildirs;
+   }
+   return config->maildirs;
+
+
+}
+
 void
 notmuch_config_set_database_path (notmuch_config_t *config,
  const char *database_path)
diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..1a9406b 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -385,14 +385,16 @@ notmuch_new_command (void *ctx,
 {
 notmuch_config_t *config;
 notmuch_database_t *notmuch;
+const struct count_ele *maildirs;
 add_files_state_t add_files_state;
 double elapsed;
 struct timeval tv_now;
-int ret = 0;
+int ret = 0, maildirs_count;
 struct stat st;
 const char *db_path;
 char *dot_notmuch_path;
 struct sigaction action;
+const char *maildir_path;

 /* Setup our handler for SIGINT */
 memset (, 0, sizeof (struct sigaction));
@@ -406,6 +408,9 @@ notmuch_new_command (void *ctx,
return 1;

 db_path = notmuch_config_get_database_path (config);
+maildirs = notmuch_config_get_maildirs (config);
+if (maildirs == NULL)
+   return 1;

 dot_notmuch_path = talloc_asprintf (ctx, "%s/%s", db_path, ".notmuch");

@@ -413,7 +418,13 @@ notmuch_new_command (void *ctx,
int count;

count = 0;
-   count_files (db_path, );
+   maildirs_count = maildirs->count;
+   maildir_path   = maildirs->ele;
+   while (maildirs_count) {
+   count_files (maildir_path, );
+   maildir_path += strlen(maildir_path) + 1;
+   maildirs_count--;
+   }
if (interrupted)
return 1;

@@ -439,7 +450,14 @@ notmuch_new_command (void *ctx,
 add_files_state.added_messages = 0;
 gettimeofday (_files_state.tv_start, NULL);

-ret = add_files (notmuch, db_path, _files_state);
+maildirs_count = maildirs->count;
+maildir_path   = maildirs->ele;
+while (maildirs_count) {
+   printf 

[notmuch] How to index /var/spool/mail with notmuch

2009-11-22 Thread Tassilo Horn
Hi all,

I'd like to try out notmuch.  My mail setup is as follows:

  - I run a local IMAP server (dovecot) and access it using Gnus
  - Dovecot stores its mails in /var/spool/mail/ in some one file per
message format

But I get some permission problems when trying to index /var/spool/mail.
I was able to create a .notmuch/ directory in there with permissions set
to 700 for my user.  All mail files are readable for my user.

Unfortunately, there are some dovecot internal files, which should
neither be indexed by notmuch, and which have 600 permissions for the
mail user.  And that's where notmuch errors and stops indexing. :-(

All "real" mail files are named "u.", so it would be cool if I
could provide a pattern to notmuch matching all files I'd like to index.
And maybe the other way round (a blacklist pattern) would be useful,
too.

Any thoughts?  Maybe there's a better approach for what I'm trying to
do?

Bye,
Tassilo


[notmuch] [PATCH] New function notmuch-search-operate-all: operate on all messages in the current query.

2009-11-22 Thread Jed Brown
It is often convenient to change tags on several messages at once.  This
function applies any number of tag whitespace-delimited tag
modifications to all messages matching the current query.

I have bound this to `*'.

Signed-off-by: Jed Brown 
---
 notmuch.el |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index a547415..b848e9a 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -764,6 +764,7 @@ thread from that buffer can be show when done with this 
one)."
 (define-key map (kbd "RET") 'notmuch-search-show-thread)
 (define-key map "+" 'notmuch-search-add-tag)
 (define-key map "-" 'notmuch-search-remove-tag)
+(define-key map "*" 'notmuch-search-operate-all)
 (define-key map "<" 'beginning-of-buffer)
 (define-key map ">" 'notmuch-search-goto-last-thread)
 (define-key map "=" 'notmuch-search-refresh-view)
@@ -940,6 +941,29 @@ This function advances point to the next line when 
finished."
   (notmuch-search-remove-tag "inbox")
   (forward-line))

+(defun notmuch-search-operate-all (action)
+  "Operate on all messages matching the current query.  Any
+number of whitespace separated actions can be given.  Each action
+must have one of the two forms
+
+  +tagname  Add the tag `tagname'
+  -tagname  Remove the tag `tagname'
+
+Each character of the tag name may consist of alphanumeric
+characters as well as `_.+-'.
+"
+  (interactive "sOperation (+add -drop): notmuch tag ")
+  (let ((action-split (split-string action " +")))
+;; Perform some validation
+(let ((words action-split))
+  (when (null words) (error "No operation given"))
+  (while words
+   (unless (string-match-p "^[\+\-][_\+\-\\w]+$" (car words))
+ (error "Action must be of the form `+thistag -that_tag'"))
+   (setq words (cdr words
+(apply 'notmuch-call-notmuch-process "tag"
+  (append action-split (list notmuch-search-query-string) nil
+
 (defun notmuch-search (query  oldest-first)
   "Run \"notmuch search\" with the given query string and display results."
   (interactive "sNotmuch search: ")
-- 
1.6.5.3



[notmuch] [PATCH 1/2] lib/message: Add function to get maildir flags.

2009-11-22 Thread Stefan Schmidt
Hello.

On Sun, 2009-11-22 at 19:55, Michiel Buddingh' wrote:
> Stefan Schmidt  wrote:
> > > This function should interpret the flags that it finds and return a
> > > suitable set of notmuch tags. I'd suggest that 'unread' messages get
> > > both 'unread' and 'inbox' tags, as Maildir doesn't distinguish between
> > > 'don't show this to be by default again please' and 'I've read this
> > > message'. It seems best to hide the maildir-specific details inside the
> > > library instead of exposing them.
> >
> > Thanks for the review. On a second thought the interface was really a bit 
> > ugly.
> > :)
> >
> > I'm just back to my box and going through the outstanding mails shows me 
> > that
> > Michiel Buddingh has a more complete patch on the
> > convert-maildir-flags-into-tags issue which Carl has tagged for review. Will
> > wait what comes out of it and if anything is left for me to. :)
> 
> Apologies.  In my haste to cover up my appalling and incorrect first patch, I
> neglected to review the archives to see if someone had already done this. 
> Sorry
> for stealing your thunder.

No need to be sorry. I'm interestecd in having this itch scratched, but don't
care who is doing it. :)

Just go ahead and get it in after Carl's review.

regards
Stefan Schmidt


[notmuch] [PATCH 1/2] lib/message: Add function to get maildir flags.

2009-11-22 Thread Michiel Buddingh'
Stefan Schmidt  wrote:
> > This function should interpret the flags that it finds and return a
> > suitable set of notmuch tags. I'd suggest that 'unread' messages get
> > both 'unread' and 'inbox' tags, as Maildir doesn't distinguish between
> > 'don't show this to be by default again please' and 'I've read this
> > message'. It seems best to hide the maildir-specific details inside the
> > library instead of exposing them.
>
> Thanks for the review. On a second thought the interface was really a bit 
> ugly.
> :)
>
> I'm just back to my box and going through the outstanding mails shows me that
> Michiel Buddingh has a more complete patch on the
> convert-maildir-flags-into-tags issue which Carl has tagged for review. Will
> wait what comes out of it and if anything is left for me to. :)

Apologies.  In my haste to cover up my appalling and incorrect first patch, I
neglected to review the archives to see if someone had already done this. Sorry
for stealing your thunder.

Michiel


[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags

2009-11-22 Thread Keith Packard
On Mon, 23 Nov 2009 04:03:12 +0100, Carl Worth  wrote:

> I agree that "normal" should be easier too. So I just need to win you
> over to my notion of "normal", (and teach you of the ways of the magic
> space bar).

As I mentioned, I rarely read mail in a linear fashion; I don't want it
to show me another message, I want to see the index again. I'm torn over
whether I just want the index to always be visible; having the full
screen available to view a single thread is awfully nice. It seems like
a 'I'm done, go back to the index' is just what is needed here.

> [*] We should perhaps fix 'a' to remove the "unread" tag from any
> messages that _are_ wholly visible in the current window. It's really
> only when an entire thread fits this one, and I *did* read it, that I
> end up reaching for the 'A' binding.

yes, that does make a lot of sense, and do precisely the same for the
'x' key, leaving 'q' the way to get out of a message without changing
it at all.

> If we did that, then we could make 'a' do archive-go-to-next-message
> and 'A' do archive-return-to-search-view. What would you think about
> that?

I'd take 'x' for 'return to search view; otherwise you're going to wear
out my pinky reaching for the shift key. That leaves us with three
commands:

'a': advance to next message, archiving current thread, marking read
messages. ('A' forces all messages in thread to be marked as read)

'x': exit to search view, archiving current thread, marking read
messages. ('X' forces all messages in thread to be marked as read)

'q': quit back to search view, leaving thread tags unmodified.

There's a slightly weird asymmetry here -- there's no way to advance to
the next thread and not mark messages.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/11c8a12a/attachment.pgp>


[notmuch] [PATCH 1/2] lib/message: Add function to get maildir flags.

2009-11-22 Thread Stefan Schmidt
Hello.

On Sat, 2009-11-21 at 16:28, Keith Packard wrote:
> On Sun, 22 Nov 2009 01:11:00 +0100, Stefan Schmidt  datenfreihafen.org> wrote:
> 
> > +const char *
> > +notmuch_message_get_flags (notmuch_message_t *message)
> 
> This function should interpret the flags that it finds and return a
> suitable set of notmuch tags. I'd suggest that 'unread' messages get
> both 'unread' and 'inbox' tags, as Maildir doesn't distinguish between
> 'don't show this to be by default again please' and 'I've read this
> message'. It seems best to hide the maildir-specific details inside the
> library instead of exposing them.

Thanks for the review. On a second thought the interface was really a bit ugly.
:)

I'm just back to my box and going through the outstanding mails shows me that
Michiel Buddingh has a more complete patch on the
convert-maildir-flags-into-tags issue which Carl has tagged for review. Will
wait what comes out of it and if anything is left for me to. :)

regards
Stefan Schmidt
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 250 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/3c68c8a9/attachment.pgp>


[notmuch] [PATCH] Add SCons build files.

2009-11-22 Thread Jed Brown
On Sun, 22 Nov 2009 10:00:26 -0600, Jeffrey Ollie  wrote:

> Yes, I'm sure that make is widely available, but as notmuch gets used
> on a wider variety of systems some sort of configuration system will
> become necessary.  If I can prevent another project from going down
> the autoconf/automake path I'll be happy.  I started creating CMake
> build files but I don't know CMake well enough to come up with a
> working build.

I can do a CMake build if that's desirable.  While I prefer it to SCons,
particularly when config/build times are an issue and you want to have
several active build trees, it is a significantly heavier dependency.
With SCons, you can dump scons-local (a pure Python script) into the
source tree and then users only need Python.  There are lots of other
lightweight build tools.

Jed


[notmuch] [PATCH 3/3] change config file location to be ~/.notmuch/config

2009-11-22 Thread Jameson Graef Rollins
On Sun, Nov 22, 2009 at 05:24:53PM -0500, Bart Trojanowski wrote:
> I totally agree with Jamie about the config rename.  I don't know if I
> agree with the database location change... but I might just need some
> convincing.

So I don't really like having the database stored in the maildir.
There are a couple reasons for this:

- I would prefer to keep all notmuch stuff together, including all
  config files, data files, etc.  In my opinion, this just makes
  things easier to keep track of.  No need to guess where any relevant
  notmuch data is if it's all stored together in one place.

- I would prefer to not clutter my mail directories with anything
  that's not mail.  The notmuch database is definitely related to my
  mail, but it's not exactly my mail, so I'd rather keep it somewhere
  else.  (I think there's a whole other thread to be started about
  this, because I think the config should also hold the location of
  the maildir to be indexed, not the path to the index itself, which
  then makes implicit assumptions about where the maildir is.)  This
  point is also probably related to the fact that I've had to change
  MUAs too many times to trust one indefinitely.  So basically I want
  to keep my mail wholly separate from anything that's processing it.

I think Carl said he wanted to keep the ability to specify exactly
where the database is stored, so if we could move away from something
that makes any implicit assumptions about relative paths between the
database and the maildir, then all should be ok.

> Would it be enough to just read .notmuch/config and fall back to
> .notmuch-config otherwise?

Yes, this is a good idea.  I'll try to come up with a patch for this.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/eb974930/attachment.pgp>


[notmuch] Guide for new users?

2009-11-22 Thread Jed Brown
On Sun, 22 Nov 2009 09:41:16 -0500, Brett Viren  
wrote:
> On Sat, Nov 21, 2009 at 11:44 PM, Jjgod Jiang  wrote:
> 
> > 1. What's the most efficient way to sync mails from my gmail
> > account to a local Maildir? I've tried offlineimap but it
> > keeps crashing python (!) on my system (python 2.6, Mac OS X
> > 10.6.2).
> 
> OfflineIMAP would have been my suggestion.

Yes, however it will change flags which changes file names and currently
confuses notmuch.  I synced [Gmail].All Mail with OfflineIMAP and am now
using Getmail to pull via POP.  In the Gmail settings, activate POP
starting at the current time.  I'll switch back to OfflineIMAP when
notmuch is happy with changing file names.

The following should save notmuch + Gmail users some time.


~/.getmail/gmail:

[retriever]
# Getmail can also do IMAP
# type = SimpleIMAPSSLRetriever
# server = imap.gmail.com
type = SimplePOP3SSLRetriever
server = pop.gmail.com
username = yourname at gmail.com
password = Pa55W0rd
# Use this with IMAP to only download one copy of each message
# mailboxes = ('[Gmail]/All Mail',)

[destination]
type = Maildir
path = ~/.mail-archive/gmail/pop/

[options]
# print messages about each action (verbose = 2)
# Other options:
# 0 prints only warnings and errors
# 1 prints messages about retrieving and deleting messages only
verbose = 2
message_log = ~/.getmail/gmail.log


With getmail, put something like this in your crontab (checks every 2
minutes)

# MIN HOUR DAY MONTH DAYOFWEEK   COMMAND
*/2 * * * * getmail -r gmail && notmuch new




~/.offlineimaprc:

[general]
accounts = GMail
maxsyncaccounts = 1
ui = Noninteractive.Basic

[Account GMail]
localrepository = Local
remoterepository = Remote
autorefresh = 1
quick = 10
postsynchook = notmuch new

[Repository Local]
type = Maildir
localfolders = /home/jed/.mail-archive/gmail/imap

[Repository Remote]
type = Gmail
folderfilter = lambda foldername: foldername in ['[Gmail]/All Mail']
remotehost = imap.gmail.com
remoteuser = yourname at gmail.com
remotepass = Pa55W0rd
ssl = yes
maxconnections = 2

#Setting realdelete = yes will Really Delete email from the server.
#Otherwise "deleting" a message will just remove any labels and
#retain the message in the All Mail folder.
realdelete = no




Note that with IMAP, your messages in '[Gmail]/All Mail' will be
delivered to a path with spaces which notmuch handles fine, but you will
need a patch

  <1258771074-25997-1-git-send-email-jed at 59A2.org>

for start-process-shell-command, e.g. to apply patches from within emacs via

  | git am



* Sending messages

To send messages from Emacs via Gmail, put something like this in your ~/.emacs

(setq smtpmail-starttls-credentials '(("smtp.gmail.com" 587 nil nil)) ; Must be 
set BEFORE loading smtpmail
  smtpmail-auth-credentials (expand-file-name "~/.authinfo")
  smtpmail-default-smtp-server "smtp.gmail.com"
  smtpmail-smtp-server "smtp.gmail.com"
  smtpmail-smtp-service 587
  smtpmail-debug-info t ; change to nil once it works
  smtpmail-debug-verb t)
(require 'smtpmail)
(setq message-send-mail-function 'smtpmail-send-it)
(require 'starttls)


you can inline authentication, but especially if you keep ~/.emacs under
version control, you should put it separately (chmod 600).

~/.authinfo:

machine smtp.gmail.com login yourname at gmail.com password Pa55W0rd port 587


* Git
Git + Gmail users can use git send-email by putting this in your
.gitconfig

[sendemail]
smtpserver = smtp.gmail.com
smtpserverport = 587
smtpencryption = tls
smtpuser = yourname at gmail.com
smtppass = Pa55W0rd



I hope this helps.

Jed


[notmuch] [PATCH -v2] notmuch.el: Add face support to search and show mode

2009-11-22 Thread Aneesh Kumar K.V
On Sun, Nov 22, 2009 at 01:02:21PM +0100, Carl Worth wrote:
> On Sun, 22 Nov 2009 14:07:56 +0530, "Aneesh Kumar K.V"  linux.vnet.ibm.com> wrote:
> > This add two faces, notmuch-show-subject-face and
> > notmuch-tag-unread-face. The first face is used to show the subject
> > line in the notmuch-show-mode and the second one to show the unread
> > tag in the notmuch-search-mode. We can set additional tags by setting
> > notmuch-tag-face-alist as below
> 
> Hi Aneesh,
> 
> I've been meaning to follow-up with you on this since I did get it
> working.
> 
> > (setq notmuch-tag-face-alist '(("unread" . 'notmuch-tag-unread-face)
> >  ("inbox" . 'notmuch-tag-inbox-face)))
> 
> It's interesting to be able to highlight specific tags like this. But I
> think that first I'd like to have a single 'notmuch-tag face to make it
> easier to see all the tag names, since they're hard to see among the
> subject. And then maybe after that have s 'notmuch-tag-important-face or
> something. I'm guessing that just that much would cover most people's
> needs, before needing to choose custom colors for each tag name.

The default search pattern for notmuch is inbox and unread right. So adding
both of them to the notmuch-tag-face-alist should color the tags properly.

> 
> > +(defface notmuch-show-subject-face
> > + 'class color) (background light)) (:foreground "yellow" :bold t))
> > +(((class color) (background dark)) (:foreground "yellow" :bold t)))
> > +  "Notmuch show mode face used to highligh subject line."
> > +  :group 'notmuch)
> 
> Color selection can be pretty difficult, and I don't think we're ever
> all going to agree on things. But I can at least say that I can't read
> yellow on white at all, (maybe yellow on black works out a bit better, I
> don't know).
> 
> So I'd definitely like to hear people's ideas on what the presentation
> should look like here.
> 
> First, the current reverse-video is definitely not something I really
> like. That was just a placeholder since I didn't know how to configure
> other faces, (and I needed _something_ to distinguish one message from
> another).
> 
> Second, from the time I spent with sup, I found that it was hard for me
> to read entire lines of bold text. So I think I'd rather just have the
> header name ("Subject:", for example) in bold and the rest of the
> subject not bold. Hmm... maybe we could use a "From:" at the beginning
> of the one line summary.
> 
> Finally, for separating one message from the other, I think I'd really
> just like a one-pixel line drawn between the last line of text of one
> message and the first line of text of the next message. Does anybody
> know how to achieve that?
> 
> Back to the patch, I think I'll be able to push it as soon as I can
> apply it and still _see_ the subject lines. ;-)

One of the easy part with emacs is we can use customize-face and select 
notmuch-show-subject-face to select what ever suites your configuration.
For me with black background i found yellow with bold to be nice.

-aneesh


[notmuch] [PATCH 3/3] change config file location to be ~/.notmuch/config

2009-11-22 Thread Bart Trojanowski
I totally agree with Jamie about the config rename.  I don't know if I
agree with the database location change... but I might just need some
convincing.

Would it be enough to just read .notmuch/config and fall back to
.notmuch-config otherwise?

-Bart

* Jameson Graef Rollins  [091122 17:15]:
> Hi, folks.  I wanted to comment on this patch request.
> 
> I personally think it makes a lot of sense to use config directories.
> This makes things much neater, since all config files can be kept in
> one place without clutter the config name space.  I can imagine down
> the line that there may be more notmuch config files, and it would be
> nicer to have a config directory rather than a bunch of ~/.notmuch-*
> files in the user dot file config space.
> 
> I also imagine this config directory as a place to store the notmuch
> database files.  I would rather keep all the notmuch data and config
> files together in one place, and keep my mail directories completely
> untouched (only read) by notmuch, if possible.
> 
> I realize, however, there is a transition problem associated with
> moving the config file, which is why I propose it be moved sooner
> rather than later.  If folks are interested in this change, and are
> worried about transition even at this early stage, we can try to come
> up with some smoother transition code.
> 
> Finally, I am (maybe clearly) *not* particularly adept at c
> programming.  I'm still learning.  I think I already have better ways
> to improve this patch.  I will try to make some improvements and send
> those along as well.
> 
> jamie.
> 
> PS. I'm sure this has already been discussed on the list, but if this
> is not the best way to send patches, please let me know.  I would be
> happy to send a pointer to my notmuch git repo if it would be
> preferable to just pull from it directly.
> 
> 
> On Sun, Nov 22, 2009 at 04:58:36PM -0500, Jameson Graef Rollins wrote:
> > This change creates a ~/.notmuch config directory where the config
> > file is stored when created with the "setup" command.  The use of a
> > ~/.notmuch config directory creates one place where all notmuch config
> > files and data can be stored, which will greatly simplify managing
> > notmuch, and reduce cluter of user dot files.
> > ---
> >  notmuch-config.c |   21 ++---
> >  notmuch-setup.c  |2 +-
> >  notmuch.1|4 ++--
> >  notmuch.c|2 +-
> >  4 files changed, 22 insertions(+), 7 deletions(-)
> > 
> > diff --git a/notmuch-config.c b/notmuch-config.c
> > index 7252a19..321c880 100644
> > --- a/notmuch-config.c
> > +++ b/notmuch-config.c
> > @@ -22,9 +22,11 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  
> >  static const char toplevel_config_comment[] =
> > -" .notmuch-config - Configuration file for the notmuch mail system\n"
> > +" .notmuch/config - Configuration file for the notmuch mail system\n"
> >  "\n"
> >  " For more information about notmuch, see http://notmuchmail.org;;
> >  
> > @@ -134,7 +136,7 @@ get_username_from_passwd_file (void *ctx)
> >  
> >  /* Open the named notmuch configuration file. A filename of NULL will
> >   * be interpreted as the default configuration file
> > - * ($HOME/.notmuch-config).
> > + * ($HOME/.notmuch/config).
> >   *
> >   * If any error occurs, (out of memory, or a permission-denied error,
> >   * etc.), this function will print a message to stderr and return
> > @@ -183,7 +185,7 @@ notmuch_config_open (void *ctx,
> >  if (filename)
> > config->filename = talloc_strdup (config, filename);
> >  else
> > -   config->filename = talloc_asprintf (config, "%s/.notmuch-config",
> > +   config->filename = talloc_asprintf (config, "%s/.notmuch/config",
> > getenv ("HOME"));
> >  
> >  config->key_file = g_key_file_new ();
> > @@ -297,14 +299,27 @@ notmuch_config_save (notmuch_config_t *config)
> >  {
> >  size_t length;
> >  char *data;
> > +char buf[256];
> >  GError *error = NULL;
> >  
> > +struct stat statbuf;
> > +
> >  data = g_key_file_to_data (config->key_file, , NULL);
> >  if (data == NULL) {
> > fprintf (stderr, "Out of memory.\n");
> > return 1;
> >  }
> >  
> > +/* Create config directory if it doesn't already exist */
> > +snprintf(buf, sizeof buf, "%s", config->filename);
> > +dirname(buf);
> > +if (stat(buf, ) < 0) {
> > +  if (mkdir(buf, 0755) < 0) {
> > +   fprintf (stderr, "Could not create directory '%s'\n.", buf);
> > +   return 1;
> > +  }
> > +}
> > +
> >  if (! g_file_set_contents (config->filename, data, length, )) {
> > fprintf (stderr, "Error saving configuration to %s: %s\n",
> >  config->filename, error->message);
> > diff --git a/notmuch-setup.c b/notmuch-setup.c
> > index 68788e1..76e104c 100644
> > --- a/notmuch-setup.c
> > +++ b/notmuch-setup.c
> > @@ -74,7 +74,7 @@ welcome_message_post_setup (void)
> >  {
> >  printf 

[notmuch] [PATCH 3/3] change config file location to be ~/.notmuch/config

2009-11-22 Thread Jameson Graef Rollins
t; -"a file in your home directory named .notmuch-config . If you'd like to\n"
> +"a file in your home directory named .notmuch/config . If you'd like to\n"
>  "change the configuration in the future, you can either edit that file\n"
>  "directly or run \"notmuch setup\".\n\n"
>  
> diff --git a/notmuch.1 b/notmuch.1
> index 8a3fb40..9ea1d42 100644
> --- a/notmuch.1
> +++ b/notmuch.1
> @@ -53,7 +53,7 @@ Interactively sets up notmuch for first use.
>  The setup command will prompt for your full name, your primary email
>  address, any alternate email addresses you use, and the directory
>  containing your email archives. Your answers will be written to a
> -configuration file in ${HOME}/.notmuch-config . This configuration
> +configuration file in ${HOME}/.notmuch/config . This configuration
>  file will be created with descriptive comments, making it easy to edit
>  by hand later to change the configuration. Or you can run
>  .B "notmuch setup"
> @@ -245,7 +245,7 @@ takes an existing set of messages and constructs a 
> suitable mail
>  template. The Reply-to header (if any, otherwise From:) is used for
>  the To: address. Vales from the To: and Cc: headers are copied, but
>  not including any of the current user's email addresses (as configured
> -in primary_mail or other_email in the .notmuch-config file) in the
> +in primary_mail or other_email in the .notmuch/config file) in the
>  recipient list
>  
>  It also builds a suitable new subject, including Re: at the front (if
> diff --git a/notmuch.c b/notmuch.c
> index 5cc8e4c..2d19a91 100644
> --- a/notmuch.c
> +++ b/notmuch.c
> @@ -98,7 +98,7 @@ command_t commands[] = {
>"\t\tThe setup command will prompt for your full name, your primary\n"
>"\t\temail address, any alternate email addresses you use, and the\n"
>"\t\tdirectory containing your email archives. Your answers will be\n"
> -  "\t\twritten to a configuration file in ${HOME}/.notmuch-config .\n"
> +  "\t\twritten to a configuration file in ${HOME}/.notmuch/config .\n"
>"\n"
>"\t\tThis configuration file will be created with descriptive\n"
>"\t\tcomments, making it easy to edit by hand later to change the\n"
> -- 
> 1.6.5
> 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/ee48dad6/attachment.pgp>


[notmuch] [PATCH] fix compiler warnings

2009-11-22 Thread Dirk-Jan C. Binnema

(hopefully this is the correct way to send patches...)

With these minor changes, notmuch compiles warning-free with gcc 4.4.1

---
 notmuch-new.c   |4 +++-
 notmuch-setup.c |   13 +++--
 notmuch-tag.c   |4 +++-
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..88b48a6 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -36,7 +36,9 @@ static void
 handle_sigint (unused (int sig))
 {
 static char msg[] = "Stopping... \n";
-write(2, msg, sizeof(msg)-1);
+if (write(2, msg, sizeof(msg)-1) < 0) {
+   /* ignore...*/
+}
 interrupted = 1;
 }

diff --git a/notmuch-setup.c b/notmuch-setup.c
index 482efd2..0d3f186 100644
--- a/notmuch-setup.c
+++ b/notmuch-setup.c
@@ -99,12 +99,13 @@ notmuch_setup_command (unused (void *ctx),
 unsigned int i;
 int is_new;

-#define prompt(format, ...)\
-do {   \
-   printf (format, ##__VA_ARGS__); \
-   fflush (stdout);\
-   getline (, _size, stdin); \
-   chomp_newline (response);   \
+#define prompt(format, ...)\
+do {   \
+   printf (format, ##__VA_ARGS__); \
+   fflush (stdout);\
+   if (getline (, _size, stdin) < 0) \
+   break;  \
+   chomp_newline (response);   \
 } while (0)

 config = notmuch_config_open (ctx, NULL, _new);
diff --git a/notmuch-tag.c b/notmuch-tag.c
index e2311f6..5e40f50 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -26,7 +26,9 @@ static void
 handle_sigint (unused (int sig))
 {
 static char msg[] = "Stopping... \n";
-write(2, msg, sizeof(msg)-1);
+if (write(2, msg, sizeof(msg)-1) < 0) {
+   /* ignore... */
+}
 interrupted = 1;
 }

-- 
1.6.3.3



[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-22 Thread Michiel Buddingh'
Dirk-Jan C. Binnema  wrote:
> Michiel> +
> Michiel> +static void
> Michiel> +derive_tags_from_maildir_flags (notmuch_message_t 
> Michiel> *message, const char *
> Michiel> path)
>
> I see you don't handle the "N" -- is that deliberate? Also, a 
> minor addition may to also allow for '!' instead of ':' as a 
> separator, as that's the semi-official way to use Maildirs on 
> (V)FAT filesystems (which don't allow for colons in filenames).

Not deliberate.  Simply unaware of the "N" flag, nor aware of 
practices for storing Maildirs on (V)FAT.

I've used only this file as a reference.
http://cr.yp.to/proto/maildir.html

mvg,
Michiel Buddingh'


[notmuch] [PATCH 3/3] change config file location to be ~/.notmuch/config

2009-11-22 Thread Jameson Graef Rollins
This change creates a ~/.notmuch config directory where the config
file is stored when created with the "setup" command.  The use of a
~/.notmuch config directory creates one place where all notmuch config
files and data can be stored, which will greatly simplify managing
notmuch, and reduce cluter of user dot files.
---
 notmuch-config.c |   21 ++---
 notmuch-setup.c  |2 +-
 notmuch.1|4 ++--
 notmuch.c|2 +-
 4 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/notmuch-config.c b/notmuch-config.c
index 7252a19..321c880 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -22,9 +22,11 @@

 #include 
 #include 
+#include 
+#include 

 static const char toplevel_config_comment[] =
-" .notmuch-config - Configuration file for the notmuch mail system\n"
+" .notmuch/config - Configuration file for the notmuch mail system\n"
 "\n"
 " For more information about notmuch, see http://notmuchmail.org;;

@@ -134,7 +136,7 @@ get_username_from_passwd_file (void *ctx)

 /* Open the named notmuch configuration file. A filename of NULL will
  * be interpreted as the default configuration file
- * ($HOME/.notmuch-config).
+ * ($HOME/.notmuch/config).
  *
  * If any error occurs, (out of memory, or a permission-denied error,
  * etc.), this function will print a message to stderr and return
@@ -183,7 +185,7 @@ notmuch_config_open (void *ctx,
 if (filename)
config->filename = talloc_strdup (config, filename);
 else
-   config->filename = talloc_asprintf (config, "%s/.notmuch-config",
+   config->filename = talloc_asprintf (config, "%s/.notmuch/config",
getenv ("HOME"));

 config->key_file = g_key_file_new ();
@@ -297,14 +299,27 @@ notmuch_config_save (notmuch_config_t *config)
 {
 size_t length;
 char *data;
+char buf[256];
 GError *error = NULL;

+struct stat statbuf;
+
 data = g_key_file_to_data (config->key_file, , NULL);
 if (data == NULL) {
fprintf (stderr, "Out of memory.\n");
return 1;
 }

+/* Create config directory if it doesn't already exist */
+snprintf(buf, sizeof buf, "%s", config->filename);
+dirname(buf);
+if (stat(buf, ) < 0) {
+  if (mkdir(buf, 0755) < 0) {
+   fprintf (stderr, "Could not create directory '%s'\n.", buf);
+   return 1;
+  }
+}
+
 if (! g_file_set_contents (config->filename, data, length, )) {
fprintf (stderr, "Error saving configuration to %s: %s\n",
 config->filename, error->message);
diff --git a/notmuch-setup.c b/notmuch-setup.c
index 68788e1..76e104c 100644
--- a/notmuch-setup.c
+++ b/notmuch-setup.c
@@ -74,7 +74,7 @@ welcome_message_post_setup (void)
 {
 printf ("\n"
 "Notmuch is now configured, and the configuration settings are saved in\n"
-"a file in your home directory named .notmuch-config . If you'd like to\n"
+"a file in your home directory named .notmuch/config . If you'd like to\n"
 "change the configuration in the future, you can either edit that file\n"
 "directly or run \"notmuch setup\".\n\n"

diff --git a/notmuch.1 b/notmuch.1
index 8a3fb40..9ea1d42 100644
--- a/notmuch.1
+++ b/notmuch.1
@@ -53,7 +53,7 @@ Interactively sets up notmuch for first use.
 The setup command will prompt for your full name, your primary email
 address, any alternate email addresses you use, and the directory
 containing your email archives. Your answers will be written to a
-configuration file in ${HOME}/.notmuch-config . This configuration
+configuration file in ${HOME}/.notmuch/config . This configuration
 file will be created with descriptive comments, making it easy to edit
 by hand later to change the configuration. Or you can run
 .B "notmuch setup"
@@ -245,7 +245,7 @@ takes an existing set of messages and constructs a suitable 
mail
 template. The Reply-to header (if any, otherwise From:) is used for
 the To: address. Vales from the To: and Cc: headers are copied, but
 not including any of the current user's email addresses (as configured
-in primary_mail or other_email in the .notmuch-config file) in the
+in primary_mail or other_email in the .notmuch/config file) in the
 recipient list

 It also builds a suitable new subject, including Re: at the front (if
diff --git a/notmuch.c b/notmuch.c
index 5cc8e4c..2d19a91 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -98,7 +98,7 @@ command_t commands[] = {
   "\t\tThe setup command will prompt for your full name, your primary\n"
   "\t\temail address, any alternate email addresses you use, and the\n"
   "\t\tdirectory containing your email archives. Your answers will be\n"
-  "\t\twritten to a configuration file in ${HOME}/.notmuch-config .\n"
+  "\t\twritten to a configuration file in ${HOME}/.notmuch/config .\n"
   "\n"
   "\t\tThis configuration file will be created with descriptive\n"
   "\t\tcomments, making it easy to edit by hand later to change the\n"
-- 

[notmuch] [PATCH 2/3] modify notmuch_setup_command to return 1 if config file write fails.

2009-11-22 Thread Jameson Graef Rollins
This fixes a small bug in notmuch_setup_command such that it returned
OK and output the setup message footer even if the config file write
step failed.
---
 notmuch-setup.c |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/notmuch-setup.c b/notmuch-setup.c
index 482efd2..68788e1 100644
--- a/notmuch-setup.c
+++ b/notmuch-setup.c
@@ -155,10 +155,11 @@ notmuch_setup_command (unused (void *ctx),
notmuch_config_set_database_path (config, absolute_path);
 }

-notmuch_config_save (config);
-
-if (is_new)
-   welcome_message_post_setup ();
-
-return 0;
+if (! notmuch_config_save (config)) {
+   if (is_new)
+ welcome_message_post_setup ();
+   return 0;
+} else {
+   return 1;
+}
 }
-- 
1.6.5



[notmuch] [PATCH 1/3] remove Makefile.config from source to allow for custom config.

2009-11-22 Thread Jameson Graef Rollins
Modified ./configure script to generate a Makefile.config if it
doesn't exist.  This will allow people to maintain custom
Makefile.config files without causing conflicts with the repository.
---
 Makefile.config |2 --
 configure   |8 
 2 files changed, 8 insertions(+), 2 deletions(-)
 delete mode 100644 Makefile.config

diff --git a/Makefile.config b/Makefile.config
deleted file mode 100644
index d72a39e..000
--- a/Makefile.config
+++ /dev/null
@@ -1,2 +0,0 @@
-prefix = /usr/local
-bash_completion_dir = /etc/bash_completion.d
diff --git a/configure b/configure
index fe46c8e..c63f70d 100755
--- a/configure
+++ b/configure
@@ -109,6 +109,14 @@ configure again to ensure the packages can be found, or 
simply run
 EOF
 exit 1
 else
+
+if [ ! -e Makefile.config ] ; then
+cat 

[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-22 Thread Michiel Buddingh'
Carl Worth  wrote:

> > A Maildir-aware notmuch could incorporate this to be far more
> > resistant to bulk mail moves done by other clients, by using
> > filename lookups to avoid accessing and parsing the mail
> > files themselves.

> I don't think opening a file to read out a message ID will ever be
> a bottleneck. But yes, we could take advantage of the unique name
> if we insisted that the storage have it.

I'm not so sure.  On traditional unix-like filesystems, every file 
access is another potential disk seek.  

People use a lot of different strategies for keeping their mail 
accessible and performant; you yourself, I gather, use non-semantic
directories mainly intended to keep the number of files per directory
low; others store their mail per month, or per year.

I might choose to move all my mail from 2008 from my INBOX to the 
folder Archive.2008; such moves may change the paths of thousands 
of messages at a time.

> Personally, I still regularly end up indexing stuff that's not 
> in proper maildir format, (like just manually copying a mail
> file "foo" down into a directory that I know isn't being delivered 
> to by any MDA but that I want notmuch to index.) Maybe that's just
> me, because I'm always bringing up little things for debugging, 
> etc. But it is convenient at least.

Oh true.  And it occurs to me that notmuch is a quite sensible 
companion tool to MH users (if they're still around in any numbers)

> Actually, I don't think that's true at all. Notmuch is definitely
> intended to become a lot more than it is right now. And if it's not
> making it easy for you to deal with mail the way you'd like to, then
> we definitely do want to look into expanding notmuch to be able to
> address that.

Thanks for your consideration; on the other hand, I do think that it
is a good idea not to make matters more complex than they need to be,
so I can certainly sympathise with the principles you've set for this
project.

regards,
Michiel Buddingh'


[notmuch] Catching up unread messages

2009-11-22 Thread Bart Trojanowski
* Tassilo Horn  [091122 16:49]:
> Ok, so new the question: I indexed all my 63.000 mails, and because it
> was a first-time indexing, all my mail now has the tags inbox and
> unread.  Of course, I don't want to SPC through all threads (using the
> great emacs interface) to remove the unread status.  So is there some
> catchup command, which marks all messages in the buffer as read?

notmuch tag -unread -- tag:unread

-Bart

-- 
WebSig: http://www.jukie.net/~bart/sig/


[notmuch] [RFC] Precedence of OR and AND

2009-11-22 Thread Bart Trojanowski
* Jed Brown  [091122 16:43]:
> Absolutely, and I have this applied locally to notmuch.el, but I didn't
> fix notmuch-search-filter-by-tag because that would really need to parse
> the expression.  I'm just asking if anyone else thinks binding OR
> tighter than AND would be desirable.

Maybe some of the ambiguity would go away if we used && and || instead
of AND and OR.  Then no matter the default, we could distinguish if
someone meant 2 or 3 tags when they typed in 'foo and bar'.

-Bart

-- 
WebSig: http://www.jukie.net/~bart/sig/


[notmuch] [RFC] Precedence of OR and AND

2009-11-22 Thread Bart Trojanowski
Wouldn't this problem be solved by each filter appending a bracketed
version of your filter?

You start with tag:inbox and you filter on "term1 or term2" you'd get:

tag:inbox and (term1 or term2)

Doing it again would result in...

tag:inbox and (term1 or term2) and (term3 or term4)

To me, it would seem the most intuitive solution.

Actually, I think I'll add that to notmuch.vim right now. :)

-Bart

* Jed Brown  [091122 16:26]:
> Currently OR binds more weakly than AND, which is natural in most
> contexts, but I think it is rarely desirably for this sort of search.
> Suppose I am in looking at my inbox and decide to filter by
> 
>   term1 OR term2
> 
> Notmuch makes the query
> 
>   tag:inbox AND term1 OR term2
> 
> which is actually
> 
>   (tag:inbox AND term1) OR term2
> 
> and not at all what I wanted.  Adding the necessary parentheses to
> notmuch-search-filter is trivial but it requires more parentheses for
> the overwhelming majority of searches that I think are more common.
> 
> Are most searches indeed closer to conjunctive form?
> 
> Should OR bind tighter than AND?
> 
> 
> Jed
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

-- 
WebSig: http://www.jukie.net/~bart/sig/


[notmuch] [PATCH] notmuch-show: Show message part using UTF-8.

2009-11-22 Thread Kan-Ru Chen
Pass the message through the charset filter so that we can view
messages wrote in different charset encoding.

Signed-off-by: Kan-Ru Chen 
---
 notmuch-show.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index d727f30..c7f1320 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -72,12 +72,19 @@ show_part_content (GMimeObject *part)
 GMimeStream *stream_stdout = g_mime_stream_file_new (stdout);
 GMimeStream *stream_filter = NULL;
 GMimeDataWrapper *wrapper;
+const char *charset;
+
+charset = g_mime_object_get_content_type_parameter (part, "charset");

 if (stream_stdout) {
g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE);
stream_filter = g_mime_stream_filter_new(stream_stdout);
g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
 g_mime_filter_crlf_new(FALSE, FALSE));
+if (charset) {
+  g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
+   g_mime_filter_charset_new(charset, 
"UTF-8"));
+}
 }

 wrapper = g_mime_part_get_content_object (GMIME_PART (part));
-- 
1.6.5.3



[notmuch] [PATCH] Add SCons build files.

2009-11-22 Thread Bart Trojanowski
My bad.  I totally misread your introduction.

* Jeffrey Ollie  [091122 11:46]:
> The SCons build files are not meant to require emacs.  If I've messed
> something up and emacs is somehow required I would consider that a bug
> and would try to fix it.
> 
> As far as availability, I'm sure that SCons is one yum or apt-get or
>  away.   The only
> people that would face more than a minor inconvenience are people that
> prefer to download tarballs and compile and install things themselves.
> 
> Yes, I'm sure that make is widely available, but as notmuch gets used
> on a wider variety of systems some sort of configuration system will
> become necessary.  If I can prevent another project from going down
> the autoconf/automake path I'll be happy.  I started creating CMake
> build files but I don't know CMake well enough to come up with a
> working build.
> 
> On 11/22/09, Bart Trojanowski  wrote:
> > * Jeffrey C. Ollie  [091122 08:47]:
> >> The SCons build files included here *should* do everything that the
> >> current Makefiles do, plus a little bit of configuration checking.  To
> >> build/install:
> >
> > Wouldn't that have the unfortunate side effect of making notmuch
> > unusable w/o emacs and scons installed?
> >
> > GNU make has a much wider install base, and notmuch is still very useful
> > without emacs.
> >
> > -Bart
> >
> > --
> > WebSig: http://www.jukie.net/~bart/sig/
> >
> 
> -- 
> Sent from my mobile device
> 
> Jeff Ollie

-- 
WebSig: http://www.jukie.net/~bart/sig/


[notmuch] [PATCH] Make notmuch-show 'X' (and 'x') commands remove inbox (and unread) tags

2009-11-22 Thread Keith Packard
On Mon, 23 Nov 2009 00:19:29 +0100, Carl Worth  wrote:

> I'm starting to come around to this patch, Keith. :-)

I'll keep posting it then :-)

> I think one thing we're going to really need is a better help message
> for presenting the keybindings. The function names are all really
> confusing, (the "notmuch-show" prefix doesn't help). So what I'd really
> like is something that displays the keybinding and the first line of the
> documentation of a function, rather than the function name itself.

That's a fine plan. It 'shouldn't' be too hard to implement either.

Btw, I'm thinking that it might be useful to create some 'global'
notmuch keybindings and then create per-view bindings that also expose
the global bindings. That way, things like 'm' to create a new mail
would work consistently in each view. Note that this idea is
inconsistent with the following though...

> Except that the patch also reverses the current behavior of "a" and
> "A". That should be a separate patch anyway, but I'm also not sure that
> I like it. I like that the command that takes the extra effort of
> pressing shift is the command that does *more*, (removing both "unread"
> and "inbox"), rather than the command that does *less*.

I was trying to make the 'normal' action easier; for me, if I'm looking
at a message, then the normal action is to mark it read and archived,
but when I'm looking only at the subject line in the search window, the
normal action is just to mark it archived (having not actually read the
message).

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/bdbe4a5c/attachment.pgp>


[notmuch] [PATCH] Add install target for desktop files.

2009-11-22 Thread Jeffrey C. Ollie
Add an install target that uses desktop-file-install to install the
desktop file in the appropriate location.  The location of the install
can be modified by changing the desktop_dir variable.

Signed-off-by: Jeffrey C. Ollie 
---
 Makefile.local |4 
 configure  |1 +
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/Makefile.local b/Makefile.local
index c87e0c4..2e7c3cd 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -45,5 +45,9 @@ install-emacs: install emacs
install -m0644 notmuch.el $(DESTDIR)$(emacs_lispdir)
install -m0644 notmuch.elc $(DESTDIR)$(emacs_lispdir)

+install-desktop:
+   install -d $(DESTDIR)$(desktop_dir)
+   desktop-file-install --mode 0644 --dir $(DESTDIR)$(desktop_dir) 
notmuch.desktop
+
 SRCS  := $(SRCS) $(notmuch_client_srcs)
 CLEAN := $(CLEAN) notmuch $(notmuch_client_modules) notmuch.elc notmuch.1.gz
diff --git a/configure b/configure
index b4770ec..1198ba7 100755
--- a/configure
+++ b/configure
@@ -132,5 +132,6 @@ EOF
 cat > Makefile.config <

[notmuch] [PATCH] Fix invalid face reference.

2009-11-22 Thread Kan-Ru Chen
To avoid the "Invalid face reference: cons [18 times]" kind of message
goes on and on in the *Messages*.

Signed-off-by: Kan-Ru Chen 
---
 notmuch.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 0144b61..a547415 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -553,7 +553,7 @@ which this thread was originally shown."
   (let ((beg (point-marker)))
 (end-of-line)
 ; Inverse video for subject
-(overlay-put (make-overlay beg (point)) 'face '((cons :inverse-video t)))
+(overlay-put (make-overlay beg (point)) 'face '(:inverse-video t))
 (forward-line 2)
 (let ((beg-hidden (point-marker)))
   (re-search-forward notmuch-show-header-end-regexp)
-- 
1.6.5.3



[notmuch] interesting project!

2009-11-22 Thread Dirk-Jan C. Binnema
Hi Carl,

> "Carl" == Carl Worth  writes:

>> Anyhow, I'll study the notmuch code and see if there are some useful
>> bits in my code that might make sense there, e.g., various dir scanning
>> optimizations, see [2].

Carl> That sounds great. It's also good to have people with experience in
Carl> this area join and help out. I'll look forward to any ideas or other
Carl> contributions you will have.

Thanks for the nice words!

A small question: it seems that notmuch is avoiding the use of GLib directly
(of course, it depend on it anyway through GMime); is this because of
OOM-handling? It'd be nice if GLib could be used, it would make some things
quite a bit easier.

Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema  Helsinki, Finland
e:djcb at djcbsoftware.nl   w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C


[notmuch] [PATCH -v2] notmuch.el: Add face support to search and show mode

2009-11-22 Thread Aneesh Kumar K.V
This add two faces, notmuch-show-subject-face and
notmuch-tag-unread-face. The first face is used to show the subject
line in the notmuch-show-mode and the second one to show the unread
tag in the notmuch-search-mode. We can set additional tags by setting
notmuch-tag-face-alist as below

(defface notmuch-tag-unread-face
 'class color) (background light)) (:foreground "goldenrod" :bold t))
(((class color) (background dark)) (:foreground "goldenrod" :bold t)))
  "Notmuch search mode face used to highligh tags.")

(defface notmuch-tag-inbox-face
 'class color) (background light)) (:foreground "red" :bold t))
(((class color) (background dark)) (:foreground "red" :bold t)))
  "Notmuch search mode face used to highligh tags.")

(setq notmuch-tag-face-alist '(("unread" . 'notmuch-tag-unread-face)
 ("inbox" . 'notmuch-tag-inbox-face)))
(require 'notmuch)

Signed-off-by: Aneesh Kumar K.V 
---
 notmuch.el |   36 ++--
 1 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 0144b61..a0f5aaa 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -637,6 +637,18 @@ which this thread was originally shown."
   (force-window-update)
   (redisplay t))

+(defface notmuch-show-subject-face
+ 'class color) (background light)) (:foreground "yellow" :bold t))
+(((class color) (background dark)) (:foreground "yellow" :bold t)))
+  "Notmuch show mode face used to highligh subject line."
+  :group 'notmuch)
+
+(defvar notmuch-show-font-lock-keywords
+  (list ;; header in font-lock-type-face
+   (list "\\(Subject:.*$\\)"
+'(1  'notmuch-show-subject-face)))
+  "Additonal expression to hightlight in notmuch-show-mode")
+
 ;;;###autoload
 (defun notmuch-show-mode ()
   "Major mode for viewing a thread with notmuch.
@@ -677,7 +689,9 @@ view, (remove the \"inbox\" tag from each), with
   (use-local-map notmuch-show-mode-map)
   (setq major-mode 'notmuch-show-mode
mode-name "notmuch-show")
-  (setq buffer-read-only t))
+  (setq buffer-read-only t)
+  (set (make-local-variable 'font-lock-defaults)
+ '(notmuch-show-font-lock-keywords t)))

 ;;;###autoload

@@ -806,6 +820,17 @@ thread from that buffer can be show when done with this 
one)."
   (goto-char (point-max))
   (forward-line -1))

+(defface notmuch-tag-unread-face
+ 'class color) (background light)) (:foreground "goldenrod" :bold t))
+(((class color) (background dark)) (:foreground "goldenrod" :bold t)))
+  "Notmuch search mode face used to highligh tags."
+  :group 'notmuch)
+
+(defvar notmuch-tag-face-alist `(("unread" . 'notmuch-tag-unread-face))
+  "List containing the tag list that need to be highlighed")
+
+(defvar notmuch-search-font-lock-keywords  nil)
+
 ;;;###autoload
 (defun notmuch-search-mode ()
   "Major mode for searching mail with notmuch.
@@ -836,7 +861,14 @@ global search.
   (setq truncate-lines t)
   (setq major-mode 'notmuch-search-mode
mode-name "notmuch-search")
-  (setq buffer-read-only t))
+  (setq buffer-read-only t)
+  (setq notmuch-search-tags (mapcar 'car notmuch-tag-face-alist))
+  (loop for notmuch-search-tag  in notmuch-search-tags
+do (add-to-list 'notmuch-search-font-lock-keywords (list
+   (concat "\\(" notmuch-search-tag "\\)")
+   `(1  ,(cdr (assoc notmuch-search-tag 
notmuch-tag-face-alist))
+  (set (make-local-variable 'font-lock-defaults)
+ '(notmuch-search-font-lock-keywords t)))

 (defun notmuch-search-find-thread-id ()
   (save-excursion
-- 
1.6.5.2.74.g610f9



[notmuch] [PATCH] makefile: Declare clean target as phony.

2009-11-22 Thread Jan Janak
This ensures that make clean always proceeds, even if the user
accidentally creates a file named 'clean'. Also, it ignores errors in
rm and other commands.

Signed-off-by: Jan Janak 
---
 Makefile |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 3553ff4..2d19a6e 100644
--- a/Makefile
+++ b/Makefile
@@ -75,5 +75,6 @@ DEPS := $(SRCS:%.c=.deps/%.d)
 DEPS := $(DEPS:%.cc=.deps/%.d)
 -include $(DEPS)

+.PHONY : clean
 clean:
rm -f $(CLEAN); rm -rf .deps
-- 
1.6.3.3



[notmuch] [PATCH] makefile: Tell echo to interpret escape sequences.

2009-11-22 Thread Jan Janak
The initial message that informs the user about the possibility to use
make V=1 contains a \n at the end, but echo wouldn't interpret that
properly without the -e command line option.
---
 Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index ae8bff1..3553ff4 100644
--- a/Makefile
+++ b/Makefile
@@ -41,7 +41,7 @@ include Makefile.config
 # user how to enable verbose compiles.
 ifeq ($(V),)
 quiet_DOC := "Use \"$(MAKE) V=1\" to see the verbose compile lines.\n"
-quiet = @echo $(quiet_DOC)$(eval quiet_DOC:=)"  $1 $@"; $($1)
+quiet = @echo -e $(quiet_DOC)$(eval quiet_DOC:=)"  $1  $@"; $($1)
 endif
 # The user has explicitly enabled quiet compilation.
 ifeq ($(V),0)
-- 
1.6.3.3



[notmuch] [PATCH] notmuch-show: Show message part using UTF-8.

2009-11-22 Thread Carl Worth
On Sun, 22 Nov 2009 16:30:47 +0800, Kan-Ru Chen  wrote:
> Pass the message through the charset filter so that we can view
> messages wrote in different charset encoding.

Thanks, very much.

We definitely want notmuch to be presenting utf-8 only to the user. And
I didn't realize I'd missed a part of this.

Pushed.

-Carl


[notmuch] [PATCH] notmuch-new: Eliminate gcc warning caused by ino_cmp.

2009-11-22 Thread Jan Janak
The function passed to scandir in the fourth argument takes two
const void* arguments. To eliminate the gcc warning about incompatible
types, we change ino_cmp to match this and then re-type the parameters
in the body of ino_cmp.

Signed-off-by: Jan Janak 
---
 notmuch-new.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..6db3d0f 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -75,9 +75,10 @@ add_files_print_progress (add_files_state_t *state)
 fflush (stdout);
 }

-static int ino_cmp(const struct dirent **a, const struct dirent **b)
+static int ino_cmp(const void *a, const void *b)
 {
-return ((*a)->d_ino < (*b)->d_ino) ? -1 : 1;
+return ((*(const struct dirent**)a)->d_ino <
+   (*(const struct dirent**)b)->d_ino) ? -1 : 1;
 }

 /* Examine 'path' recursively as follows:
-- 
1.6.3.3



[notmuch] [PATCH] Missing final semi-colon in .desktop's Categories.

2009-11-22 Thread Carl Worth
On Sun, 22 Nov 2009 01:07:49 -0600, Jeffrey Ollie  wrote:
> Found the same problem on my own, only to minutes later catch up on
> the backlog of patches in my email and find this!
...
> > Signed-off-by: James Rowe 
> 
> Reviewed-by: Jeffrey C. Ollie 

Much thanks, James and Jeffrey!

I always feel *much* more comfortable pushing a patch I haven't tested
personally if someone else has reviewed it.

-Carl


[notmuch] [PATCH] Fix invalid face reference.

2009-11-22 Thread Carl Worth
On Sun, 22 Nov 2009 14:40:59 +0800, Kan-Ru Chen  wrote:
> To avoid the "Invalid face reference: cons [18 times]" kind of message
> goes on and on in the *Messages*.

Thanks. This is pushed.

And welcome to notmuch, Kan-Ru! I'll look forward to any possible
contributions from you in the future.

-Carl


[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-22 Thread Carl Worth
[quick reply to the text without looking at the patch yet]

On Sun, 22 Nov 2009 10:33:53 +0100, Michiel Buddingh'  wrote:
> Thanks, and apologies for the accidental base64 encoding.

Thanks for noticing. That would have been a tricky patch to reply to to
comment on.

> On the positive side, this allows us to map these flags onto tags,
> at least for indexing (the patch at the bottom implements this), and,
> if I can pry you away from your principles, later for modification
> as well.

Yes, we might end up doing this. We'll see.

> I respect your desire to stick to that principle.  But I also know 
> that purity and simplicity, generally speaking, are unattainable
> luxuries for most applications that handle mail.

Hehe. Thanks for the entertainment. You sound like someone who's already
got some of the battle scars from trying to write mail-handling
software. One is certainly forced to see an awful lot of awfully strange
things.

> Another thing; notmuch currently indexes by message-id (or SHA-1 hash
> if that is not present).  Maildir, on the other hand, uses file names
> as stable (when stripped of the parts trailing the colon) unique 
> (knock on wood) identifiers.  A Maildir-aware notmuch could incorporate
> this to be far more resistant to bulk mail moves done by other clients,
> by using filename lookups to avoid accessing and parsing the mail 
> files themselves.

I don't think opening a file to read out a message ID will ever be a
bottleneck. But yes, we could take advantage of the unique name if we
insisted that the storage have it.

Personally, I still regularly end up indexing stuff that's not in proper
maildir format, (like just manually copying a mail file "foo" down into
a directory that I know isn't being delivered to by any MDA but that I
want notmuch to index.) Maybe that's just me, because I'm always
bringing up little things for debugging, etc. But it is convenient at
least.

So I think I'd like to be careful to avoid notmuch ever *requiring*
maildir storage. (But yes, it should obviously support maildir well
since it's so common.)

> I should re-iterate that I'm new to notmuch, and it's obvious that I'm
> trying to beat it into becoming something it was never intended to be;

Actually, I don't think that's true at all. Notmuch is definitely
intended to become a lot more than it is right now. And if it's not
making it easy for you to deal with mail the way you'd like to, then
we definitely do want to look into expanding notmuch to be able to
address that.

> on the other hand, I'd like people to chime in on this.

I've got the patch tagged to give a closer look at it later.

Thanks again,

-Carl


[notmuch] [PATCH -v2] notmuch.el: Add face support to search and show mode

2009-11-22 Thread Carl Worth
On Sun, 22 Nov 2009 14:07:56 +0530, "Aneesh Kumar K.V"  wrote:
> This add two faces, notmuch-show-subject-face and
> notmuch-tag-unread-face. The first face is used to show the subject
> line in the notmuch-show-mode and the second one to show the unread
> tag in the notmuch-search-mode. We can set additional tags by setting
> notmuch-tag-face-alist as below

Hi Aneesh,

I've been meaning to follow-up with you on this since I did get it
working.

> (setq notmuch-tag-face-alist '(("unread" . 'notmuch-tag-unread-face)
>("inbox" . 'notmuch-tag-inbox-face)))

It's interesting to be able to highlight specific tags like this. But I
think that first I'd like to have a single 'notmuch-tag face to make it
easier to see all the tag names, since they're hard to see among the
subject. And then maybe after that have s 'notmuch-tag-important-face or
something. I'm guessing that just that much would cover most people's
needs, before needing to choose custom colors for each tag name.

> +(defface notmuch-show-subject-face
> + 'class color) (background light)) (:foreground "yellow" :bold t))
> +(((class color) (background dark)) (:foreground "yellow" :bold t)))
> +  "Notmuch show mode face used to highligh subject line."
> +  :group 'notmuch)

Color selection can be pretty difficult, and I don't think we're ever
all going to agree on things. But I can at least say that I can't read
yellow on white at all, (maybe yellow on black works out a bit better, I
don't know).

So I'd definitely like to hear people's ideas on what the presentation
should look like here.

First, the current reverse-video is definitely not something I really
like. That was just a placeholder since I didn't know how to configure
other faces, (and I needed _something_ to distinguish one message from
another).

Second, from the time I spent with sup, I found that it was hard for me
to read entire lines of bold text. So I think I'd rather just have the
header name ("Subject:", for example) in bold and the rest of the
subject not bold. Hmm... maybe we could use a "From:" at the beginning
of the one line summary.

Finally, for separating one message from the other, I think I'd really
just like a one-pixel line drawn between the last line of text of one
message and the first line of text of the next message. Does anybody
know how to achieve that?

Back to the patch, I think I'll be able to push it as soon as I can
apply it and still _see_ the subject lines. ;-)

-Carl


[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-22 Thread Dirk-Jan C. Binnema
Hi Michiel,

> "Michiel" == Michiel Buddingh'  writes:

Michiel> Another thing; notmuch currently indexes by message-id (or SHA-1
Michiel> hash if that is not present).  Maildir, on the other hand, uses
Michiel> file names as stable (when stripped of the parts trailing the
Michiel> colon) unique (knock on wood) identifiers.  A Maildir-aware
Michiel> notmuch could incorporate this to be far more resistant to bulk
Michiel> mail moves done by other clients, by using filename lookups to
Michiel> avoid accessing and parsing the mail files themselves.

I think that is a good idea.

Michiel> I should re-iterate that I'm new to notmuch, and it's obvious
Michiel> that I'm trying to beat it into becoming something it was never
Michiel> intended to be; on the other hand, I'd like people to chime in on
Michiel> this.

I'm new here too, so please be gentle as I learn how things work

Michiel> +
Michiel> +static void
Michiel> +derive_tags_from_maildir_flags (notmuch_message_t *message, const 
char *
Michiel> path)

I see you don't handle the "N" -- is that deliberate? Also, a minor addition
may to also allow for '!' instead of ':' as a separator, as that's the
semi-official way to use Maildirs on (V)FAT filesystems (which don't allow for
colons in filenames).


Best wishes,
Dirk.


-- 
Dirk-Jan C. Binnema  Helsinki, Finland
e:djcb at djcbsoftware.nl   w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C


[notmuch] Guide for new users?

2009-11-22 Thread Jjgod Jiang
Hi,

I think it will be nice if we can have a guide/tutorial like
documentation for new users. For myself, I have the following
questions (I am an alpine user previously, so some of the
questions are not related to notmuch directly):

1. What's the most efficient way to sync mails from my gmail
account to a local Maildir? I've tried offlineimap but it
keeps crashing python (!) on my system (python 2.6, Mac OS X
10.6.2).

2. How to add notmuch.el into my .emacsrc?

I know notmuch feels like a tool for geeks, but it will probably
lower the barrier if someone can provide such a guide in a
straightforward, step-by-step way.

- Jiang


[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-22 Thread Dirk-Jan C. Binnema
> "Carl" == Carl Worth  writes:

Carl> On Sun, 22 Nov 2009 00:25:43 +0100, Michiel Buddingh'
Carl>  wrote:

Carl> Hi Michel, welcome to Notmuch!

>> Any attempt to match tags up to directories will eventually have 
>> to deal with with the fact that tags can't be neatly mapped onto 
>> them.  If I remove a directory-tag from a message, does this 
>> mean the message is removed from that directory?  What if a 
>> message has two directory-tags, does it mean it's present in both
>> directories?

Carl> Right. We definitely don't want a strong mapping here. I think one
Carl> answer could be that the initial import is different and can take the
Carl> directory names as a "hint" for initializing tag values. After that,
Carl> they are just tags in the database and the user can do whatever they
Carl> want.

In 'mu' I took a slightly different approach, by simply allowing for searches
on the path to the message; ie., by adding the path as just another property
of the message, just like subject: or from:.

Now, the trouble with that the path of a message is not very stable -- people
move messages around. In 'mu' this was handled by simply considering the moved
message as a new one, and removing message from the database whose paths do
not point to message anymore. This makes things quite robust against people
moving things around or deleting them. Tags could be connected to the
hopefully unique Maildir file name then. 

Carl>   notmuch search tag:foo and not tag:foo-search
Carl>   notmuch search tag:foo-search and not tag:foo

Carl> So even if in the end the user comes up with something that could
Carl> replace the original tag, it's probably still beneficial to have it
Carl> there when starting out.

So, an alternative would be something like:
 notmuch search path:inbox

But this requires notmuch to be able to update things when paths change.

Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema  Helsinki, Finland
e:djcb at djcbsoftware.nl   w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C


[notmuch] [PATCH] Mac OS X compatibility fixes

2009-11-22 Thread Jjgod Jiang
Hi Alex,

On Sun, Nov 22, 2009 at 12:17 PM, Alexander Botero-Lowry
 wrote:
>> +#ifdef __APPLE__
> Not awesome.
>
> This should be done in a capabilites way, for example strndup was added
> to FreeBSD in 7.2 (which is this current release of the 7 line), and so
> for older versions of FreeBSD strndup will be needed. getdelim() and
> getline() came in FreeBSD 8, so they'll be needed for the entire 7 line.
> So Instead of just assuming __APPLE__ this should be done by determing
> if the symbols are generally needed.

The problem is that notmuch does not have a fully functional configure
process yet, Carl did mention Makefile.local, but it seems this file is
not generated by configure right now. (No config.h either.)

I will be happy to fix my patch if such facility (like
AC_CHECK_FUNCS([getline])) exists.

- Jiang


[notmuch] [PATCH] fix notmuch-new bug when database path ends with a trailing /

2009-11-22 Thread Bart Trojanowski
I configured my database.path with a trailing /, and after running notmuch
new every notmuch search would fail with error messages like this:

  Error opening /inbox/cur/1258565257.000211.mbox:2,S: No such file or directory

The actual bug was in the filename normalization for storage in the
database.  The database.path was removed from the full filename, but if
the database.path from the config file contained a trailing /, the
relative file name would retain an extra leading /... which made it look
like an absolute path after it was read out from the DB.

Signed-off-by: Bart Trojanowski 
---
 lib/message.cc |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index 017c47b..1e325e2 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -411,10 +411,14 @@ _notmuch_message_set_filename (notmuch_message_t *message,
 db_path = notmuch_database_get_path (message->notmuch);
 db_path_len = strlen (db_path);

-if (*s == '/' && strncmp (s, db_path, db_path_len) == 0
-   && strlen (s) > db_path_len)
+if (*s == '/' && strlen (s) > db_path_len
+   && strncmp (s, db_path, db_path_len) == 0)
 {
-   s += db_path_len + 1;
+   s += db_path_len;
+   while (*s == '/') s++;
+
+   if (!*s)
+   INTERNAL_ERROR ("Message filename was same as db prefix.");
 }

 message->doc.set_data (s);
-- 
1.6.4.4.2.gc2f148



[notmuch] [PATCH] Mac OS X compatibility fixes

2009-11-22 Thread Jjgod Jiang
Add missing GNU extensions strdup() and getline(). The C library
shipped with Mac OS X does not include them (though it does support
some GNU extensions when _GNU_SOURCE is defined), so we have to
add these two. The getline() implementation is a modified version
of getdelim() from GNU Libc.
---
 lib/xutil.c |   99 +++
 lib/xutil.h |6 +++
 2 files changed, 105 insertions(+), 0 deletions(-)

diff --git a/lib/xutil.c b/lib/xutil.c
index 6fa5eb0..805b236 100644
--- a/lib/xutil.c
+++ b/lib/xutil.c
@@ -79,6 +79,105 @@ xstrdup (const char *s)
 return ret;
 }

+#ifdef __APPLE__
+/* Mac OS X don't have strndup even if _GNU_SOURCE is defined */
+char *strndup (const char *s, size_t n)
+{
+size_t len = strlen (s);
+char *ret;
+
+if (len <= n)
+   return strdup (s);
+
+ret = malloc(n + 1);
+strncpy(ret, s, n);
+ret[n] = '\0';
+return ret;
+}
+
+/* getline implementation is copied from glibc. */
+
+#ifndef SIZE_MAX
+# define SIZE_MAX ((size_t) -1)
+#endif
+#ifndef SSIZE_MAX
+# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
+#endif
+
+ssize_t getline (char **lineptr, size_t *n, FILE *fp)
+{
+ssize_t result;
+size_t cur_len = 0;
+
+if (lineptr == NULL || n == NULL || fp == NULL)
+{
+   errno = EINVAL;
+   return -1;
+}
+
+if (*lineptr == NULL || *n == 0)
+{
+   *n = 120;
+   *lineptr = (char *) malloc (*n);
+   if (*lineptr == NULL)
+   {
+   result = -1;
+   goto end;
+   }
+}
+
+for (;;)
+{
+   int i;
+
+   i = getc (fp);
+   if (i == EOF)
+   {
+   result = -1;
+   break;
+   }
+
+   /* Make enough space for len+1 (for final NUL) bytes.  */
+   if (cur_len + 1 >= *n)
+   {
+   size_t needed_max =
+   SSIZE_MAX < SIZE_MAX ? (size_t) SSIZE_MAX + 1 : SIZE_MAX;
+   size_t needed = 2 * *n + 1;   /* Be generous. */
+   char *new_lineptr;
+
+   if (needed_max < needed)
+   needed = needed_max;
+   if (cur_len + 1 >= needed)
+   {
+   result = -1;
+   goto end;
+   }
+
+   new_lineptr = (char *) realloc (*lineptr, needed);
+   if (new_lineptr == NULL)
+   {
+   result = -1;
+   goto end;
+   }
+
+   *lineptr = new_lineptr;
+   *n = needed;
+   }
+
+   (*lineptr)[cur_len] = i;
+   cur_len++;
+
+   if (i == '\n')
+   break;
+}
+(*lineptr)[cur_len] = '\0';
+result = cur_len ? (ssize_t) cur_len : result;
+
+end:
+return result;
+}
+#endif
+
 char *
 xstrndup (const char *s, size_t n)
 {
diff --git a/lib/xutil.h b/lib/xutil.h
index b973f7d..0b53f7c 100644
--- a/lib/xutil.h
+++ b/lib/xutil.h
@@ -25,6 +25,12 @@
 #include 
 #include 

+#ifdef __APPLE__
+/* Mac OS X don't have strndup and getline even if _GNU_SOURCE is defined */
+char *strndup (const char *s, size_t n);
+ssize_t getline(char **lineptr, size_t *n, FILE *stream);
+#endif
+
 /* xutil.c */
 void *
 xcalloc (size_t nmemb, size_t size);
-- 
1.6.4



[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-22 Thread Michiel Buddingh'

On Sun, 22 Nov 2009 05:04:56 +0100, Carl Worth  wrote:
> Hi Michel, welcome to Notmuch!

Thanks, and apologies for the accidental base64 encoding.

First things first:

>> In the mean time, I've made a smaller, hopefully more harmless 
>> patch to let 'notmuch new' mark messages stored in a Maildir 'cur'
>> folder as 'read' rather than 'unread'.
> 
> Can others who have more experience weigh in here? Will this do the
> right thing for you? Do mail clients wait to move things into "cur"
> after the user has actually read them, or is that just a place where
> they are moved when the MUA _receives_ them?

You're absolutely right, and I'm a fool (because I _knew_ this, but
forgot).  Maildir stores flags (seen, replied, flagged, trashed,
passed) in file names.

On the positive side, this allows us to map these flags onto tags,
at least for indexing (the patch at the bottom implements this), and,
if I can pry you away from your principles, later for modification
as well.

>> Any attempt to match tags up to directories will eventually have 
>> to deal with with the fact that tags can't be neatly mapped onto 
>> them.  If I remove a directory-tag from a message, does this 
>> mean the message is removed from that directory?  What if a 
>> message has two directory-tags, does it mean it's present in both
>> directories?
> 
> Right. We definitely don't want a strong mapping here.

I propose that the maildir 'storage_type' could make an exception for
standard Maildir flags.  It'll take relatively little effort to
special-case the abovementioned flags, and it'd be a huge boon to
interoperability.

>> At the same time, this kind of interoperability would be highly
>> desirable to those of us who access their mail using other  
>> clients (webmail, mobile phones, etc.) that expect hierarchical
>> ordering.
> 
> That kind of thing is going to be "harder".
> 
> So far we're trying to stick with the principle that notmuch itself
> doesn't mess with the data store.

I respect your desire to stick to that principle.  But I also know 
that purity and simplicity, generally speaking, are unattainable
luxuries for most applications that handle mail.

> But then, we also want notmuch to be
> very scriptable, so someone might write a tool that uses notmuch search
> to export a set of hierarchical maildirs based on the tag names. (These
> could even just be populated with symlinks like mairix does.) So
> something like that could be really useful for integrating.

That is a very interesting idea.  On the other hand, interoperability
with Maildir mail stores is unlikely to be a corner case.  The MTA is
probably going to deliver new mail to a Maildir, procmail understands it,
etc.  I'd feel more comfortable relegating this integration to a 
scripted glue layer if I knew for certain such a glue layer would be
up to the task.

> I'm very much of the opinion that the user shouldn't care at all about
> the storage of the actual mail files that notmuch indexes.

The user certainly shouldn't, but I'm not sure that notmuch can remain
as agnostic about the actual storage of messages as planned.

Another thing; notmuch currently indexes by message-id (or SHA-1 hash
if that is not present).  Maildir, on the other hand, uses file names
as stable (when stripped of the parts trailing the colon) unique 
(knock on wood) identifiers.  A Maildir-aware notmuch could incorporate
this to be far more resistant to bulk mail moves done by other clients,
by using filename lookups to avoid accessing and parsing the mail 
files themselves.

I should re-iterate that I'm new to notmuch, and it's obvious that I'm
trying to beat it into becoming something it was never intended to be;
on the other hand, I'd like people to chime in on this.

again via webmail,
Michiel Buddingh'

---
 notmuch-client.h |   10 ++
 notmuch-config.c |   33 +--
 notmuch-new.c|   95
+++--
 3 files changed, 124 insertions(+), 14 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index ea77686..c39be06 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -69,12 +69,16 @@
 #define STRNCMP_LITERAL(var, literal) \
 strncmp ((var), (literal), sizeof (literal) - 1)

+enum storage_type { UNSET, NONE, MAILDIR };
+
 typedef void (*add_files_callback_t) (notmuch_message_t *message);

 typedef struct {
 int ignore_read_only_directories;
 int saw_read_only_directory;

+enum storage_type storage_type;
+
 int total_files;
 int processed_files;
 int added_messages;
@@ -179,7 +183,13 @@ notmuch_config_set_user_other_email (notmuch_config_t
*config,
 const char *other_email[],
 size_t length);

+enum storage_type
+notmuch_config_get_storage_type (notmuch_config_t *config);
+
 notmuch_bool_t
 debugger_is_active (void);

+
+
+
 #endif
diff --git a/notmuch-config.c b/notmuch-config.c
index aaa0372..13bd341 100644
--- 

[notmuch] 25 minutes load time with emacs -f notmuch

2009-11-22 Thread Brett Viren
On Sun, Nov 22, 2009 at 3:36 AM, Mike Hommey  wrote:

> A good test, if you have enough memory, would be to put your mailbox in
> a tmpfs, and see how fast that imports.

(Oops, forgot to reply to the list.)

I don't see any function calls related to I/O on the call graph.

But, here is one that looks I/O bound:

 notmuch tag -unread tag:inbox

I have my home directory on an encfs volume and I see it and notmuch
competing for CPU when viewing "top".

-Brett.


[notmuch] [PATCH] Add SCons build files.

2009-11-22 Thread Jeffrey Ollie
The SCons build files are not meant to require emacs.  If I've messed
something up and emacs is somehow required I would consider that a bug
and would try to fix it.

As far as availability, I'm sure that SCons is one yum or apt-get or
 away.   The only
people that would face more than a minor inconvenience are people that
prefer to download tarballs and compile and install things themselves.

Yes, I'm sure that make is widely available, but as notmuch gets used
on a wider variety of systems some sort of configuration system will
become necessary.  If I can prevent another project from going down
the autoconf/automake path I'll be happy.  I started creating CMake
build files but I don't know CMake well enough to come up with a
working build.

On 11/22/09, Bart Trojanowski  wrote:
> * Jeffrey C. Ollie  [091122 08:47]:
>> The SCons build files included here *should* do everything that the
>> current Makefiles do, plus a little bit of configuration checking.  To
>> build/install:
>
> Wouldn't that have the unfortunate side effect of making notmuch
> unusable w/o emacs and scons installed?
>
> GNU make has a much wider install base, and notmuch is still very useful
> without emacs.
>
> -Bart
>
> --
>   WebSig: http://www.jukie.net/~bart/sig/
>

-- 
Sent from my mobile device

Jeff Ollie


[notmuch] Guide for new users?

2009-11-22 Thread Brett Viren
On Sat, Nov 21, 2009 at 11:44 PM, Jjgod Jiang  wrote:

> 1. What's the most efficient way to sync mails from my gmail
> account to a local Maildir? I've tried offlineimap but it
> keeps crashing python (!) on my system (python 2.6, Mac OS X
> 10.6.2).

OfflineIMAP would have been my suggestion.

> 2. How to add notmuch.el into my .emacsrc?
>
> I know notmuch feels like a tool for geeks, but it will probably
> lower the barrier if someone can provide such a guide in a
> straightforward, step-by-step way.

I put notmuch.el in an ~/.emacs.d/ directory.  Then add this to your
.emacs file:

(add-to-list 'load-path (expand-file-name "~/.emacs.d"))
(require 'notmuch)

In the session type "M-x notmuch".

-Brett.


[notmuch] 25 minutes load time with emacs -f notmuch

2009-11-22 Thread Mike Hommey
On Sat, Nov 21, 2009 at 05:36:18PM -0500, Brett Viren wrote:
> On Sat, Nov 21, 2009 at 12:07 PM, Carl Worth  wrote:
> 
> > Though, frankly, I think we need to fix "notmuch new" to do much better
> > than 40 files/sec.
> 
> Just a "me too".
> 
> Processed 130871 total files in 38m 7s (57 files/sec.).
> Added 102723 new messages to the database (not much, really).
> 
> This was ~2GB of mail on a 2.5GHz CPU.  That seems pretty reasonable
> to me but I'd like to rerun the "notmuch new" under google perftools
> to see if there are any obvious bottlenecks that might be cleaned up.

FWIW, my 90k+ messages mailbox was imported at a pace of 130 files/sec,
and my CPU is "only" 2.2GHz, but I have a SSD. A good share of the
bottlenecks is "simply" I/O. Don't forget having a lot of small files
sucks I/O wise, as files are most likely spread all over the disk.

A good test, if you have enough memory, would be to put your mailbox in
a tmpfs, and see how fast that imports.

Mike


[notmuch] [PATCH] Add SCons build files.

2009-11-22 Thread Bart Trojanowski
* Jeffrey C. Ollie  [091122 08:47]:
> The SCons build files included here *should* do everything that the
> current Makefiles do, plus a little bit of configuration checking.  To
> build/install:

Wouldn't that have the unfortunate side effect of making notmuch
unusable w/o emacs and scons installed?

GNU make has a much wider install base, and notmuch is still very useful
without emacs.

-Bart

-- 
WebSig: http://www.jukie.net/~bart/sig/


[notmuch] [PATCH] Add SCons build files.

2009-11-22 Thread Jeffrey C. Ollie
The SCons build files included here *should* do everything that the
current Makefiles do, plus a little bit of configuration checking.  To
build/install:

scons all emacs
sudo scons install
sudo scons install-emacs
sudo scons install-desktop

Various installation directories can be customized:

sudo scons install DESTDIR=/tmp/buildroot prefix=/opt/notmuch

See the output of 'scons -h' for a complete list of the variables that
can be modified.

Signed-off-by: Jeffrey C. Ollie 
---
 .gitignore |3 +
 SConstruct |  226 
 lib/SConscript |   19 +
 3 files changed, 248 insertions(+), 0 deletions(-)
 create mode 100644 SConstruct
 create mode 100644 lib/SConscript

diff --git a/.gitignore b/.gitignore
index 8794354..6661b3b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,6 @@ notmuch.1.gz
 *~
 .*.swp
 *.elc
+.sconsign.dblite
+.sconf_temp
+config.log
diff --git a/SConstruct b/SConstruct
new file mode 100644
index 000..8d6960d
--- /dev/null
+++ b/SConstruct
@@ -0,0 +1,226 @@
+# -*- mode: python; coding: utf-8 -*-
+
+import os
+
+variables = Variables('custom.py')
+
+variables.Add('DESTDIR',
+  'Destination directory',
+  '')
+
+variables.Add('prefix',
+  'Installation prefix',
+  '/usr/local')
+
+variables.Add('bindir',
+  'Directory that user binaries go into',
+  '${prefix}/bin')
+
+variables.Add('datadir',
+  'Directory that static data files go into',
+  '${prefix}/share')
+
+variables.Add('mandir',
+  'Directory that manual pages go into',
+  '${datadir}/man')
+
+variables.Add('emacs_lispdir',
+  'Directory that Emacs LISP files go into',
+  '${default_emacs_lispdir}')
+
+variables.Add('sysconfdir',
+  'Directory that system configuration files go into',
+  '/etc')
+
+variables.Add('bash_completion_dir',
+  'Directory that Bash completion files go into',
+  '${sysconfdir}/bash_completion.d')
+
+variables.Add('desktop_dir',
+  'Directory that desktop files go into',
+  '${datadir}/applications')
+
+variables.Add('gzip',
+  'Gzip executable',
+  'gzip')
+
+variables.Add('emacs',
+  'Emacs executable',
+  'emacs')
+
+def InstallPerm(env, dest, files, perm):
+obj = env.Install(dest, files)
+for i in obj:
+env.AddPostAction(i, Chmod(str(i), perm))
+return dest
+
+def InstallAsPerm(env, dest, files, perm):
+obj = env.InstallAs(dest, files)
+for i in obj:
+env.AddPostAction(i, Chmod(str(i), perm))
+return dest
+
+topenv = Environment(variables = variables,
+ BUILDERS = {'InstallPerm': InstallPerm,
+ 'InstallAsPerm': InstallAsPerm})
+
+topenv.Append(CPPPATH=['#/lib'])
+
+cflags = None
+if os.environ.has_key('CFLAGS'):
+cflags = topenv.ParseFlags(os.environ['CFLAGS'])
+topenv.MergeFlags(cflags)
+
+if os.environ.has_key('CXXFLAGS'):
+cxxflags = topenv.ParseFlags(os.environ['CXXFLAGS'])
+topenv.MergeFlags(cxxflags)
+
+if cflags is None or cxxflags is None:
+optflags = topenv.ParseFlags('-O2')
+topenv.MergeFlags(optflags)
+
+warnflags = topenv.ParseFlags('-Wall -Wextra -Wmissing-declarations 
-Wwrite-strings -Wswitch-enum')
+topenv.MergeFlags(warnflags)
+
+def CheckPkgConfig(context, version):
+context.Message('Checking for pkg-config... ')
+result = context.TryAction('pkg-config --atleast-pkgconfig-version=%s' % 
version)[0]
+context.Result(result)
+return result
+ 
+def CheckPkg(context, name):
+context.Message('Checking for %s... ' % name)
+result = context.TryAction('pkg-config --exists \'%s\'' % name)[0]
+context.Result(result)
+return result
+
+def CheckXapian(context):
+context.Message('Checking for xapian-core... ')
+for xapian_config in ['xapian-config-1.1', 'xapian-config']:
+result, output = context.TryAction('%s --version > $TARGET' % 
xapian_config)
+if result:
+xapian_version = output.strip().split()[-1]
+context.env['xapian_config'] = xapian_config
+context.env['xapian_version'] = xapian_version
+context.Result(xapian_version)
+return result
+context.Result(False)
+return False
+
+def CheckEmacs(context):
+context.Message('Checking for emacs... ')
+context.env['default_emacs_lispdir'] = '${prefix}/share/emacs/site-lisp'
+result = context.TryAction('pkg-config --exists emacs')
+if result:
+result, output = context.TryAction('pkg-config emacs --variable 
sitepkglispdir > $TARGET')
+if result:
+context.env['default_emacs_lispdir'] = output.strip()
+context.Result(True)
+return True
+context.Result(False)
+return False
+
+def CheckDesktopFileInstall(context):
+

[notmuch] hijacked threads can be confusing in notmuch

2009-11-22 Thread Carl Worth
On Sat, 21 Nov 2009 21:18:34 -0500, Bart Trojanowski  wrote:
> In mutt it looked like this:
> 
>   [notmuch] [PATCH 1/3] Make mouse-1 click in search view show thread
>   ??>[notmuch] [PATCH 2/3] Add 'notmuch count' command to show the count of 
> matching messages
> ??>[notmuch] [PATCH 3/3] Add notmuch-index mode to display message counts
> 
> ... and in the mutt threaded display the relationship between the three
> messages is pretty clear.
> 
> Now consider what happens when I run notmuch search 'notmuch count'.  I
> get this:
> 
>   Today 02:15 [2/3] Keith Packard; [notmuch] [PATCH 1/3] Make mouse-1
>   click in search view show thread (inbox unread)

Hmm... that's a bug.

What notmuch *should* be doing here is taking as the subject of the
thread the subject of the first message in the thread that matched,
(rather than the subject of the first message in the thread).

The thread_create has all that information, (it constructs two
lists---one of all its messages, and one of matched messages).

Now the next step is still missing. Let's say that instead of 2/3
mesages matched in the thread, (and by the way, did you all now that
that's what's being reported there? it's not the number of unread
messages or anything like that, but the number of matched
messages). Anyway, let's say you had something like 1/20 there
instead. And let's also assume that there aren't any unread messages in
the thread.

Then when you go to view that thread you will see all the messages open,
and you won't have any information as to which message matched. What
*should* happen here is that only the messages that matched should be
open, and the messages that didn't match should be closed. Currently,
the various pieces of the system don't have access to the information
they need for this result. One way to do it would be to make "notmuch
search" return a list of message IDs rather than a thread ID and then
emacs could pass that list to "notmuch show". Alternately, the emacs
interface could pass the current thread ID to "notmuch show" but also
pass along the search string and then "notmuch show" could indicate
which messages matched the search.

Another thing to decide is how this relates with the default behavior of
opening unread messages but closing read messages. Would possibility
there could be to make that work just like any other search, just as I
described above. If we were to go that route, I think it might mean
getting rid of the distinction between "inbox" and "unread", and I'm not
sure I want to do that or not.

Anyway, I'd love to hear some ideas.

> On a related note, one mail related pet peeve I have is when people
> reply to a random email in their mailbox when they actually intend to
> start a new thread.  Doing that would totally mess up someone using
> notmuch.  They could get search results with threads which have no
> relevance to their actual search... at least at first glance.

Hopefully, the fix of displaying the subject from the first matched
message would help here.

-Carl


[notmuch] [PATCH 1/2] notmuch-new: Only install SIGALRM if not running under gdb

2009-11-22 Thread Carl Worth
On Sun, 22 Nov 2009 00:44:31 +, Chris Wilson  
wrote:
> I felt sorry for Carl trying to step through an exception from xapian
> and suffering from the SIGALARMs..

You're too kind, Chris. These are both pushed.

And did you notice the way I didn't push as soon as I found your patches
in my inbox, but this time I looked for the *next* set of patches. ;-)

-Carl


[notmuch] [PATCH] lib/database.cc: coding style

2009-11-22 Thread Carl Worth
On Sat, 21 Nov 2009 23:14:39 +, Chris Wilson  
wrote:
> Carl claims he must have been distracted when he wrote this...

Indeed. Thanks for keeping my sloppy code looking so clean.

-Carl


[notmuch] suggestion/request about notmuch config

2009-11-22 Thread Carl Worth
On Sat, 21 Nov 2009 18:06:38 -0500, Jameson Graef Rollins  wrote:
> Hi, folks.  I just recently heard about notmuch and am very excited by
> it.  It looks like exactly what I've been waiting years for.  Also
> excited to see so much good development work happening.

Hi Jamie, welcome to notmuch!

> I would prefer to see all notmuch files and data in the same
> directory, preferably:
> 
> ~/.notmuch
> 
> The config file could be:
> 
> ~/.notmuch/config
> 
> and the database could be:
> 
> ~/.notmuch/db

I suppose that's totally reasonable, (though I wouldn't abbreviate
"database" to "db"). I think the only thing I'd miss is that I can
currently point the config file to a different database, (which is
usually just for testing.)

And really, for that what I really want is a "-f" option to the notmuch
command to make it read from a specified configuration file. So if I had
that option then I don't think I'd mind this change at all.

> Let me know what people think.  Looking forward to working with
> notmuch!

And I'm looking forward to your contributions.

Thanks again,

-Carl


[notmuch] RFC: Multiple filenames for email messages

2009-11-22 Thread Carl Worth
On Sat, 21 Nov 2009 23:37:24 +0100, Jan Janak  wrote:
> The comment of _notmuch_message_set_filename says:
> 
>XXX: We should still figure out if we think it's important to store
>multiple filenames for email messages with identical message IDs.
...
> I'd like to propose that we store all filenames for email messages in
> the database, not just one per message. I'd be happy to work on it and
> submit a patch if others think that this would be good to have.

Oh, sure. As soon as we start using filenames for searches, then that
makes a lot of sense.

Currently, notmuch isn't storing any filename that way, but should be,
(need to just add a prefix to the table at the top of lib/database.cc,
document it, and then make the indexing stage generate terms from the
filename with that prefix).

The term generator and query parser should do the right thing, which is
to split the filename into individual terms at each '/', store position
data with each, and then turn a search like:

filename:some/filename/segment

into a phrase search that looks for the terms "some", "filename", and
"segment", each with the filename prefix you choose and each in
sequential position. Note that if you compile notmuch with CFLAGS
including -DDEBUG then you'll see a nice report of the post-parsed query
that's useful for debugging stuff like this.

The reason for my comment was related to the other use of the filename,
(that is, the only one we're currently using). This is with regard to
querying the database for the actual filename, rather than searching on
it. For this, we don't use terms, but instead use the "data" field of
the document. I was wondering if in the presentation of an email message
it would ever be important to have access to the multiple files.

Can anyone think of a case where they would need that? That is, a case
where you care about the distinct content of two messages that have the
same message ID?

I suppose that in the case of getting a message by two paths, (say
through a mailing list and also via CC), one might want to inspect the
different headers in the two versions. So maybe we'll need to break down
and provide this information to the interfaces.

Also, if we're going to support file deletion well, then I suppose we
really will need to store all the filenames, (so if one disappears we
can still point to the others). Also, we'll need to be able to
accurately update the filename terms when a message disappears, so that
means having all of the complete filenames around.

So I guess I'm convincing myself that we really should store all the
filenames, and also provide an interface to get a list of filenames for
a message, (but also expect that many users of the API will only want to
look at the first filename in the list).

-Carl


[notmuch] [PATCH] Permit opening the notmuch database in read-only mode.

2009-11-22 Thread Carl Worth
On Sat, 21 Nov 2009 20:08:31 +, Chris Wilson  
wrote:
> [ickle: Updated to add WRITABLE mode to notmuch-new]

Oops. I committed your earlier version, but then fixed this up
afterwards myself.

-Carl


[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages

2009-11-22 Thread Carl Worth
On Sun, 22 Nov 2009 00:25:43 +0100, Michiel Buddingh'  wrote:
> (hi, new here, just subscribed today.  Wanted to reply to Carl's 
>  earlier message I read in the archives, but since I don't have that,
>  I'm replying to Bart's reply to that message)

Hi Michel, welcome to Notmuch!

> Any attempt to match tags up to directories will eventually have 
> to deal with with the fact that tags can't be neatly mapped onto 
> them.  If I remove a directory-tag from a message, does this 
> mean the message is removed from that directory?  What if a 
> message has two directory-tags, does it mean it's present in both
> directories?

Right. We definitely don't want a strong mapping here. I think one
answer could be that the initial import is different and can take the
directory names as a "hint" for initializing tag values. After that,
they are just tags in the database and the user can do whatever they
want.

This would mean that the user will need some other way to apply tags to
future messages that might be delivered to those same directories. And
we've got search-based tagging for that, (as well as manual tagging for
the case where a user was manually filing messages into folders before).

And while developing these search-based tags the user can use a
different tag name. Say there was a directory named "foo", then the user
might experiment with a search-based tag named "foo-search" and explore
the results of things like:

notmuch search tag:foo and not tag:foo-search
notmuch search tag:foo-search and not tag:foo

So even if in the end the user comes up with something that could
replace the original tag, it's probably still beneficial to have it
there when starting out.

> At the same time, this kind of interoperability would be highly
> desirable to those of us who access their mail using other  
> clients (webmail, mobile phones, etc.) that expect hierarchical
> ordering.

That kind of thing is going to be "harder".

So far we're trying to stick with the principle that notmuch itself
doesn't mess with the data store. But then, we also want notmuch to be
very scriptable, so someone might write a tool that uses notmuch search
to export a set of hierarchical maildirs based on the tag names. (These
could even just be populated with symlinks like mairix does.) So
something like that could be really useful for integrating.

I'm very much of the opinion that the user shouldn't care at all about
the storage of the actual mail files that notmuch indexes.

> In the mean time, I've made a smaller, hopefully more harmless 
> patch to let 'notmuch new' mark messages stored in a Maildir 'cur'
> folder as 'read' rather than 'unread'.

Can others who have more experience weigh in here? Will this do the
right thing for you? Do mail clients wait to move things into "cur"
after the user has actually read them, or is that just a place where
they are moved when the MUA _receives_ them?

-Carl


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

2009-11-22 Thread Carl Worth
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] Makefile: Magic silent rules.

2009-11-22 Thread Mikhail Gusarov

Twas brillig at 20:32:20 21.11.2009 UTC+00 when chris at chris-wilson.co.uk did 
gyre and gimble:

 CW> Use the facilities of GNU make to create a magic function that will
 CW> on the first invocation print a description of how to enable
 CW> verbose compile lines and then print the quiet rule.

Uhm. Now it eats much less :)

$ make
...
  GZIP  notmuch.1.gz
/bin/sh: --rsyncable: not found
make: *** [notmuch.1.gz] Error 127
$

$ make V=1
...
rsyncable --stdout notmuch.1 > notmuch.1.gz
/bin/sh: rsyncable: not found
make: [notmuch.1.gz] Error 127 (ignored)
$

-- 
  http://fossarchy.blogspot.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/76c25d69/attachment.pgp>


[notmuch] [PATCH] Makefile: Magic silent rules.

2009-11-22 Thread Carl Worth
On Sun, 22 Nov 2009 04:50:41 +0600, Mikhail Gusarov  wrote:
> Uhm. Now it eats much less :)
> 
> $ make
> ...
>   GZIPnotmuch.1.gz
> /bin/sh: --rsyncable: not found
> make: *** [notmuch.1.gz] Error 127
> $
> 
> $ make V=1
> ...
> rsyncable --stdout notmuch.1 > notmuch.1.gz
> /bin/sh: rsyncable: not found
> make: [notmuch.1.gz] Error 127 (ignored)

The bug here was in using the GZIP variable assuming it would be a
program name. But since gzip expects it to be additional arguments, we
need to use a different name such as a "gzip" variable.

Thanks for the original implementation, Chris. And thanks for the
testing, Mikhail.

I've pushed the original plus the below on top.

-Carl

commit 1266d8511e9adc7296ec4ddbf609dec824b4c94f
Author: Carl Worth 
Date:   Sun Nov 22 04:45:16 2009 +0100

Makefile: Fix to work even with GZIP environment variable set.

The rule here was written to assume that if the GZIP environment
variable was set that it would be the gzip binary to execute,
(similar to the CC and CXX variables). But GZIP is actually used
to pass arguments to gzip, so we have to use a different name.

diff --git a/Makefile b/Makefile
index 5d8f321..ae8bff1 100644
--- a/Makefile
+++ b/Makefile
@@ -4,7 +4,9 @@ CFLAGS=-O2

 # Additional programs that are used during the compilation process.
 EMACS ?= emacs
-GZIP ?= gzip
+# Lowercase to avoid clash with GZIP environment variable for passing
+# arguments to gzip.
+gzip = gzip

 # Additional flags that we will append to whatever the user set.
 # These aren't intended for the user to manipulate.
diff --git a/Makefile.local b/Makefile.local
index 5fd5d4f..b6d3db3 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -23,7 +23,7 @@ notmuch: $(notmuch_client_modules) lib/notmuch.a
$(call quiet,CXX) $^ $(LDFLAGS) -o $@

 notmuch.1.gz: notmuch.1
-   $(call quiet,GZIP) --stdout $^ > $@
+   $(call quiet,gzip) --stdout $^ > $@

 install: all notmuch.1.gz
for d in $(DESTDIR)$(prefix)/bin/ $(DESTDIR)$(prefix)/share/man/man1 \


[notmuch] 25 minutes load time with emacs -f notmuch

2009-11-22 Thread Carl Worth
On Sat, 21 Nov 2009 17:36:18 -0500, Brett Viren  
wrote:
> Processed 130871 total files in 38m 7s (57 files/sec.).
> Added 102723 new messages to the database (not much, really).

Just be glad that you have so little mail. ;-)

> This was ~2GB of mail on a 2.5GHz CPU.  That seems pretty reasonable
> to me but I'd like to rerun the "notmuch new" under google perftools
> to see if there are any obvious bottlenecks that might be cleaned up.

To me, here are the obvious things to fix after looking at a profile:

  1. We're spending a *lot* of time searching in the Xapian database.

But our initial indexing operation should only be *writing* data into
the database, so what's this searching about?

Well, at each new message, we're looking up the ID from it's In-Reply-To
header to find a thread-ID to link to, and then we're looking up all of
the IDs from its References header to find thread IDs that need to be
merged with ours. So both parent and child lookups.

And since those are taking a bunch of time, I think it might make sense
to just keep a hashtable mapping message-ID -> thread-ID and do lookups
in that, (should have plenty of memory on current machines even with
lots of mail).

  2. We're hitting the slow Xapian document updates for thread-ID
  merging.

Whenever we find a child that was already in the database with one
thread ID that should have ours, we simply want to set its thread ID to
ours. But as we've talked about recently, Xapian has a bug (defect 250)
that makes it much more expensive than it should be to update a single
term.

So, we could do a first pass over the messages to find all their thread
IDs and get them to settle down before doing any indexing in a separate,
second pass.

Step (2) should help even if we don't do step (1), but clearly we can do
both.

It would be great if anyone wants to take a look at either or both of
these, otherwise I will when I can.

-Carl


[notmuch] Segfault with weird Message-ID

2009-11-22 Thread Carl Worth
On Sat, 21 Nov 2009 23:26:15 +0100, Mike Hommey  
wrote:
> I just was able to reproduce after starting over.

Thanks Mike. I was able to reproduce this as well by eliminating the
spurious blank line I had on the 2nd or 3rd line. (So maybe that managed
to sneak in when you sent me the message.)

> header isn't "", and message_id is correctly filled. I can also confirm
> the exception is thrown from notmuch->xapian_db->add_document.

Yes. We were trying to add a term that is too long for Xapian. I've
fixed this by simply falling back to our existing sha-1 code when a
message ID is long.

Thanks so much for the bug report!

-Carl

commit 5d56e931b99d575dbb0b936d24aae5e9903861ad
Author: Carl Worth 
Date:   Sun Nov 22 04:03:49 2009 +0100

add_message: Use sha-1 in place of overly long message ID.

Since Xapian has a limit on the maximum length of a term, we have
to check for that before trying to add the message ID as a term.

This fixes the bug reported by Mike Hommey here:

<20091120132625.GA19246 at glandium.org>

I've also constructed 20 files with a range of message ID lengths
centered around the Xapian term-length limit which I'll use to seed a
new test suite soon.

diff --git a/lib/database.cc b/lib/database.cc
index 169dc5e..f4a445a 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -892,7 +892,7 @@ notmuch_database_add_message (notmuch_database_t *notmuch,

 const char *date, *header;
 const char *from, *to, *subject;
-char *message_id;
+char *message_id = NULL;

 if (message_ret)
*message_ret = NULL;
@@ -937,11 +937,20 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
header = notmuch_message_file_get_header (message_file, "message-id");
if (header && *header != '\0') {
message_id = _parse_message_id (message_file, header, NULL);
+
/* So the header value isn't RFC-compliant, but it's
 * better than no message-id at all. */
if (message_id == NULL)
message_id = talloc_strdup (message_file, header);
-   } else {
+
+   /* Reject a Message ID that's too long. */
+   if (message_id && strlen (message_id) + 1 > NOTMUCH_TERM_MAX) {
+   talloc_free (message_id);
+   message_id = NULL;
+   }
+   }
+
+   if (message_id == NULL ) {
/* No message-id at all, let's generate one by taking a
 * hash over the file's contents. */
char *sha1 = notmuch_sha1_of_file (filename);


[notmuch] [PATCH] Makefile: Magic silent rules.

2009-11-22 Thread Mikhail Gusarov

Twas brillig at 19:02:22 21.11.2009 UTC+00 when chris at chris-wilson.co.uk did 
gyre and gimble:

 CW> Use the facilities of GNU make to create a magic function that will
 CW> on the first invocation print a description of how to enable
 CW> verbose compile lines and then print the quiet rule.

Ugh. With silent rules enabled it gives me

/bin/sh: --rsyncable: not found

at the end (apparently gzip was eaten out)

And with V=1 it strips first two symbols from the command name:

c -Wall -Wextra -Wmissing-declarations -Wwrite-strings -Wswitch-enum 
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/gmime-2.4   -Ilib  lib/query.cc -o 
lib/query.o
make: c: Command not found
make: [lib/query.o] Error 127 (ignored)
c -Wall -Wextra -Wmissing-declarations -Wwrite-strings -Wswitch-enum 
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/gmime-2.4   -Ilib  lib/thread.cc -o 
lib/thread.o
make: c: Command not found
make: [lib/thread.o] Error 127 (ignored)
rcs lib/notmuch.a lib/libsha1.o lib/message-file.o lib/messages.o lib/sha1.o 
lib/tags.o lib/xutil.o lib/database.o lib/index.o lib/message.o lib/query.o 
lib/thread.o
make: rcs: Command not found


-- 
  http://fossarchy.blogspot.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091122/83d17991/attachment.pgp>


[notmuch] [PATCH 2/2] notmuch-new: Tag mails not as unread when the seen flag in the maildir is set.

2009-11-22 Thread Stefan Schmidt
With the new notmuch_message_get_flags() function we can get the information if
a message was already flagged as seen in maildir by another mailer or tool. This
gives a more realistic picture instead of flagging all as unread.

Signed-off-by: Stefan Schmidt 
---
 Makefile  |2 +-
 notmuch-new.c |   16 +++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 3fedcf1..dfcfc70 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 # Default FLAGS, (can be overridden by user such as "make CFLAGS=-O2")
 WARN_FLAGS=-Wall -Wextra -Wmissing-declarations -Wwrite-strings -Wswitch-enum
-CFLAGS=-O2
+CFLAGS=-O0 -ggdb3

 # Additional flags that we will append to whatever the user set.
 # These aren't intended for the user to manipulate.
diff --git a/notmuch-new.c b/notmuch-new.c
index bc35b4e..ef4429d 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -41,8 +41,22 @@ handle_sigint (unused (int sig))
 static void
 tag_inbox_and_unread (notmuch_message_t *message)
 {
-notmuch_message_add_tag (message, "inbox");
+char *buf;
+int i;
+
+buf = notmuch_message_get_flags (message);
+for (i = 0; i < strlen (buf); i++) {
+/* If the S flag is set the message can be tagged as read */
+if (buf[i] == 'S') {
+notmuch_message_add_tag (message, "read");
+goto inbox;
+}
+}
+
 notmuch_message_add_tag (message, "unread");
+
+inbox:
+notmuch_message_add_tag (message, "inbox");
 }

 static void
-- 
1.6.5.3



[notmuch] [PATCH] Missing final semi-colon in .desktop's Categories.

2009-11-22 Thread Jeffrey Ollie
Found the same problem on my own, only to minutes later catch up on
the backlog of patches in my email and find this!

On Sat, Nov 21, 2009 at 3:13 AM, James Rowe  wrote:
> "Those keys which have several values should have a semicolon as the trailing
> character."
> ?-- http://standards.freedesktop.org/desktop-entry-spec/1.0/ar01s03.html
>
> Signed-off-by: James Rowe 

Reviewed-by: Jeffrey C. Ollie 

> ---
> ?notmuch.desktop | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/notmuch.desktop b/notmuch.desktop
> index d29dff6..819cd1e 100644
> --- a/notmuch.desktop
> +++ b/notmuch.desktop
> @@ -4,4 +4,4 @@ Exec=emacs -f notmuch
> ?Icon=emblem-mail
> ?Terminal=false
> ?Type=Application
> -Categories=Network;Email
> +Categories=Network;Email;
> --
> 1.6.4.4
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>



-- 
Jeff Ollie


[notmuch] [PATCH] notmuch-new: Eliminate tallocs whilst construct filenames.

2009-11-22 Thread Chris Wilson
The majority of filenames will fit within PATH_MAX [4096] (because
that's a hard limit imposed by the filesystems) so we can avoid an
allocation per lookup and thereby eliminate a large proportion of the
overhead of scanning a maildir.

Signed-off-by: Chris Wilson 
---
 notmuch-new.c |   75 ++--
 1 files changed, 45 insertions(+), 30 deletions(-)

diff --git a/notmuch-new.c b/notmuch-new.c
index 0dd2784..13559d1 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -107,6 +107,7 @@ add_files_recursive (notmuch_database_t *notmuch,
 add_files_state_t *state)
 {
 DIR *dir = NULL;
+char buf[4096];
 struct dirent *entry = NULL;
 char *next = NULL;
 time_t path_mtime, path_dbtime;
@@ -114,6 +115,7 @@ add_files_recursive (notmuch_database_t *notmuch,
 notmuch_message_t *message = NULL;
 struct dirent **namelist = NULL;
 int num_entries;
+int path_len, dname_len;

 /* If we're told to, we bail out on encountering a read-only
  * directory, (with this being a clear clue from the user to
@@ -140,6 +142,12 @@ add_files_recursive (notmuch_database_t *notmuch,

 int i=0;

+path_len = strlen (path);
+if (path_len + 2 < (int) sizeof (buf)) {
+   memcpy (buf, path, path_len);
+   buf[path_len] = '/';
+}
+
 while (!interrupted) {
if (i == num_entries)
break;
@@ -164,37 +172,42 @@ add_files_recursive (notmuch_database_t *notmuch,
continue;
}

-   next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);
+   dname_len = strlen (entry->d_name);
+   if (path_len + dname_len + 2 < (int) sizeof (buf)) {
+   memcpy (buf + path_len + 1, entry->d_name, dname_len);
+   buf[path_len + dname_len + 1] = '\0';
+   next = buf;
+   } else {
+   next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);
+   }

if (stat (next, st)) {
fprintf (stderr, "Error reading %s: %s\n",
 next, strerror (errno));
ret = NOTMUCH_STATUS_FILE_ERROR;
-   continue;
-   }
-
-   if (S_ISREG (st->st_mode)) {
-   /* If the file hasn't been modified since the last
-* add_files, then we need not look at it. */
-   if (path_dbtime == 0 || st->st_mtime > path_dbtime) {
-   state->processed_files++;
-
-   status = notmuch_database_add_message (notmuch, next, );
-   switch (status) {
-   /* success */
+   } else {
+   if (S_ISREG (st->st_mode)) {
+   /* If the file hasn't been modified since the last
+* add_files, then we need not look at it. */
+   if (path_dbtime == 0 || st->st_mtime > path_dbtime) {
+   state->processed_files++;
+
+   status = notmuch_database_add_message (notmuch, next, 
);
+   switch (status) {
+   /* success */
case NOTMUCH_STATUS_SUCCESS:
state->added_messages++;
tag_inbox_and_unread (message);
break;
-   /* Non-fatal issues (go on to next file) */
+   /* Non-fatal issues (go on to next file) */
case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:
-   /* Stay silent on this one. */
+   /* Stay silent on this one. */
break;
case NOTMUCH_STATUS_FILE_NOT_EMAIL:
fprintf (stderr, "Note: Ignoring non-mail file: %s\n",
 next);
break;
-   /* Fatal issues. Don't process anymore. */
+   /* Fatal issues. Don't process anymore. */
case NOTMUCH_STATUS_READONLY_DATABASE:
case NOTMUCH_STATUS_XAPIAN_EXCEPTION:
case NOTMUCH_STATUS_OUT_OF_MEMORY:
@@ -210,25 +223,27 @@ add_files_recursive (notmuch_database_t *notmuch,
case NOTMUCH_STATUS_LAST_STATUS:
INTERNAL_ERROR ("add_message returned unexpected value: 
%d",  status);
goto DONE;
-   }
+   }

-   if (message) {
-   notmuch_message_destroy (message);
-   message = NULL;
-   }
+   if (message) {
+   notmuch_message_destroy (message);
+   message = NULL;
+   }

-   if (do_add_files_print_progress) {
-   do_add_files_print_progress = 0;
-   add_files_print_progress (state);
+   if (do_add_files_print_progress) {
+   do_add_files_print_progress = 0;
+   add_files_print_progress (state);
+   

[notmuch] [PATCH 2/2] notmuch-new: Only print the regular progress report when on a tty

2009-11-22 Thread Chris Wilson
Check that the stdout is connected to an interactive terminal with
isatty() before installing the periodic timer to print progress reports.

Signed-off-by: Chris Wilson 
---
 notmuch-new.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/notmuch-new.c b/notmuch-new.c
index 1616ee9..0dd2784 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -20,6 +20,8 @@

 #include "notmuch-client.h"

+#include 
+
 static volatile sig_atomic_t do_add_files_print_progress = 0;

 static void
@@ -273,7 +275,7 @@ add_files (notmuch_database_t *notmuch,
 }

 /* Setup our handler for SIGALRM */
-if (! debugger_is_active ()) {
+if (isatty (fileno (stdout)) && ! debugger_is_active ()) {
memset (, 0, sizeof (struct sigaction));
action.sa_handler = handle_sigalrm;
sigemptyset (_mask);
-- 
1.6.5.3



[notmuch] [PATCH 1/2] notmuch-new: Only install SIGALRM if not running under gdb

2009-11-22 Thread Chris Wilson
I felt sorry for Carl trying to step through an exception from xapian
and suffering from the SIGALARMs..

We can detect if the user launched notmuch under a debugger by either
checking our cmdline for the presence of the gdb string or querying if
valgrind is controlling our process. For the latter we need to add a
compile time check for the valgrind development library, and so add the
initial support to build Makefile.config from configure.

Signed-off-by: Chris Wilson 
Reviewed-by: Carl Worth 
[ickle: And do not install the timer when under the debugger]
---
 Makefile.config  |1 +
 Makefile.local   |3 ++-
 configure|   21 +
 debugger.c   |   47 +++
 notmuch-client.h |3 +++
 notmuch-new.c|   49 -
 6 files changed, 98 insertions(+), 26 deletions(-)
 create mode 100644 debugger.c

diff --git a/Makefile.config b/Makefile.config
index d72a39e..ddc7436 100644
--- a/Makefile.config
+++ b/Makefile.config
@@ -1,2 +1,3 @@
 prefix = /usr/local
 bash_completion_dir = /etc/bash_completion.d
+CFLAGS += -DHAVE_VALGRIND
diff --git a/Makefile.local b/Makefile.local
index 3c99624..efe76c8 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -3,6 +3,8 @@ all: notmuch notmuch.1.gz
 emacs: notmuch.elc

 notmuch_client_srcs =  \
+   debugger.c  \
+   gmime-filter-reply.c\
notmuch.c   \
notmuch-config.c\
notmuch-dump.c  \
@@ -14,7 +16,6 @@ notmuch_client_srcs = \
notmuch-show.c  \
notmuch-tag.c   \
notmuch-time.c  \
-   gmime-filter-reply.c\
query-string.c  \
show-message.c

diff --git a/configure b/configure
index fe46c8e..b4770ec 100755
--- a/configure
+++ b/configure
@@ -53,6 +53,14 @@ else
 errors=$((errors + 1))
 fi

+if pkg-config --modversion valgrind > /dev/null 2>&1; then
+echo "Checking for valgrind development files... Yes."
+have_valgrind=-DHAVE_VALGRIND
+else
+echo "Checking for valgrind development files... No."
+have_valgrind=
+fi
+
 if [ $errors -gt 0 ]; then
 cat < Makefile.config 

[notmuch] Avoid installing SIGALRMs when under the debugger.

2009-11-22 Thread Chris Wilson
Gah, I'm tired and using "git send-email HEAD^" is too easy. Here is the
most recent pair of patches in possibly a working state.
-ickle



[notmuch] [PATCH] notmuch-new: Only install SIGALRM if not running under gdb

2009-11-22 Thread Chris Wilson
I felt sorry for Carl trying to step through an exception from xapian
and suffering from the SIGALARMs..

We can detect if the user launched notmuch under a debugger by either
checking our cmdline for the presence of the gdb string or querying if
valgrind is controlling our process. For the latter we need to add a
compile time check for the valgrind development library, and so add the
initial support to build Makefile.config from configure.

Signed-off-by: Chris Wilson 
Reviewed-by: Carl Worth 
[ickle: And do not install the timer]
---
 Makefile.config  |1 +
 Makefile.local   |3 ++-
 configure|   21 +
 debugger.c   |   47 +++
 notmuch-client.h |3 +++
 notmuch-new.c|   12 +++-
 6 files changed, 77 insertions(+), 10 deletions(-)
 create mode 100644 debugger.c

diff --git a/Makefile.config b/Makefile.config
index d72a39e..ddc7436 100644
--- a/Makefile.config
+++ b/Makefile.config
@@ -1,2 +1,3 @@
 prefix = /usr/local
 bash_completion_dir = /etc/bash_completion.d
+CFLAGS += -DHAVE_VALGRIND
diff --git a/Makefile.local b/Makefile.local
index 3c99624..efe76c8 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -3,6 +3,8 @@ all: notmuch notmuch.1.gz
 emacs: notmuch.elc

 notmuch_client_srcs =  \
+   debugger.c  \
+   gmime-filter-reply.c\
notmuch.c   \
notmuch-config.c\
notmuch-dump.c  \
@@ -14,7 +16,6 @@ notmuch_client_srcs = \
notmuch-show.c  \
notmuch-tag.c   \
notmuch-time.c  \
-   gmime-filter-reply.c\
query-string.c  \
show-message.c

diff --git a/configure b/configure
index fe46c8e..b4770ec 100755
--- a/configure
+++ b/configure
@@ -53,6 +53,14 @@ else
 errors=$((errors + 1))
 fi

+if pkg-config --modversion valgrind > /dev/null 2>&1; then
+echo "Checking for valgrind development files... Yes."
+have_valgrind=-DHAVE_VALGRIND
+else
+echo "Checking for valgrind development files... No."
+have_valgrind=
+fi
+
 if [ $errors -gt 0 ]; then
 cat < Makefile.config 

[notmuch] [PATCH] notmuch-config: Fix memleaks.

2009-11-22 Thread Carl Worth
On Sat, 21 Nov 2009 23:17:02 +0100, Stefan Schmidt  wrote:
> 
> While talloc is great we need to free the g_error by hand.
> 
> Tested-by: Stefan Schmidt 
> Signed-off-by: Holger Freyther 

Thanks to both of you! This is pushed.

As for talloc and glib, it's become clear to me that I'd really like a
talloc-friendly hash-table implementation, (and maybe a nice growing
array). I really haven't seen any other data structures in glib that I'd
need as universally as I need those, (particularly since talloc already
provides a bunch of string functions).

-Carl


[notmuch] [PATCH] notmuch-new: Only install SIGALRM if not running under gdb

2009-11-22 Thread Chris Wilson
I felt sorry for Carl trying to step through an exception from xapian
and suffering from the SIGALARMs..

We can detect if the user launched notmuch under a debugger by either
checking our cmdline for the presence of the gdb string or querying if
valgrind is controlling our process. For the latter we need to add a
compile time check for the valgrind development library, and so add the
initial support to build Makefile.config from configure.

Signed-off-by: Chris Wilson 
Reviewed-by: Carl Worth 
---
 Makefile.config  |1 +
 Makefile.local   |3 ++-
 configure|   21 +
 debugger.c   |   47 +++
 notmuch-client.h |3 +++
 notmuch-new.c|   12 +++-
 6 files changed, 77 insertions(+), 10 deletions(-)
 create mode 100644 debugger.c

diff --git a/Makefile.config b/Makefile.config
index d72a39e..ddc7436 100644
--- a/Makefile.config
+++ b/Makefile.config
@@ -1,2 +1,3 @@
 prefix = /usr/local
 bash_completion_dir = /etc/bash_completion.d
+CFLAGS += -DHAVE_VALGRIND
diff --git a/Makefile.local b/Makefile.local
index 3c99624..efe76c8 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -3,6 +3,8 @@ all: notmuch notmuch.1.gz
 emacs: notmuch.elc

 notmuch_client_srcs =  \
+   debugger.c  \
+   gmime-filter-reply.c\
notmuch.c   \
notmuch-config.c\
notmuch-dump.c  \
@@ -14,7 +16,6 @@ notmuch_client_srcs = \
notmuch-show.c  \
notmuch-tag.c   \
notmuch-time.c  \
-   gmime-filter-reply.c\
query-string.c  \
show-message.c

diff --git a/configure b/configure
index fe46c8e..b4770ec 100755
--- a/configure
+++ b/configure
@@ -53,6 +53,14 @@ else
 errors=$((errors + 1))
 fi

+if pkg-config --modversion valgrind > /dev/null 2>&1; then
+echo "Checking for valgrind development files... Yes."
+have_valgrind=-DHAVE_VALGRIND
+else
+echo "Checking for valgrind development files... No."
+have_valgrind=
+fi
+
 if [ $errors -gt 0 ]; then
 cat < Makefile.config 

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

2009-11-22 Thread Jed Brown
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.

2009-11-22 Thread Carl Worth
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] notmuch new: Support for conversion of spool subdirectories into tags

2009-11-22 Thread Jan Janak
On Sat, Nov 21, 2009 at 7:44 PM, Carl Worth  wrote:
> On Wed, 18 Nov 2009 05:57:03 +0100, Jan Janak  wrote:
>> This patch makes it possible to convert subdirectory names inside the
>> spool directory into message tags. Messages stored in subdirectory
>> "foo" will be marked with tag "foo". Message duplicates found in several
>> subdirectories will be given one tag per subdirectory.
>
> Hi Jan,
>
> I just pushed out a patch from Aneesh for similar functionality, but
> with a simpler implementation.
>
> One thing that patch loses is the addition of multiple tags when a
> message appears in multiple directories. Would you like to code up that
> feature on top of the current code?

Looking at the commit log history, I noticed that you reverted the
commit, so I guess this question is no more relevant.

By the way, although I provided a similar patch some time ago, I agree
that it is better not to have this hard-wired in 'notmuch-new'. It
helped me with the initial import, but since then I have been trying
to get it working with a script run after 'notmuch-new'.

   -- Jan