[notmuch] [patch] store folder information

[Michal Sojka]

On Wednesday 27 of January 2010 16:55:55 micah anderson wrote:
> have not seen a reply from you yet. I'm particularly eager to see this
> get accepted upstream, and it sounds like the changes necessary to do so
> are relatively minor.

Hi Micah and others,

I wanted to test this patch, so I rebased it to the current HEAD. I had to do 
it manually since notmuch evolved significantly since the original posting. 
I'll post in followup mails.

> I'm wondering what your plans are for addressing these issues? I've come
> to depend on this functionality, and would love to see it incorporated
> upstream!
> 
> Specifically these were:
> 
> 1. Unrelated whitespace:

Fixed.

> 2. An unrelated hunk creeping in:
> 
> On Tue, 15 Dec 2009 13:22:19 -0800, Carl Worth  wrote:
> > On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl=C3=B6ckner
> >  
> tiker.net> wrote:
> > > @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
> > >   s++;
> > >   if (strncasecmp (s, "re:", 3) =3D=3D 0)
> > >   s +=3D 3;
> > > +else if (strncasecmp (s, "aw:", 3) =3D=3D 0)
> > > + s +=3D 3;
> > >   else
> > >   break;
> > >  }

Fixed.

> 3. Redundant trailing directory name traversal:
> > > +gchar *full_folder_name =3D NULL;
> > > +gchar *folder_base_name =3D NULL;
> > > +
> > > +/* Find name of "folder" containing the email. */
> > > +full_folder_name =3D g_strdup(path);
> > > +while (1)
> > > +{
> > > +folder_base_name =3D g_path_get_basename(full_folder_name);
> >
> > The trailing directory name is available already during the
> > traversal. So you don't need to search it back out again. See the patch
> > in the following message:
> >
> > id:87fx8bygi7.fsf at linux.vnet.ibm.com
> >
> > which simply passes the trailing directory name along, (but skipping a
> > name of "cur" or "new" while traversing).
> 
> 4. supporting hierarchical folders (perhaps this is a later improvement
> 
> that does not need to be added before the original patch is accepted?):
> > Beyond that, though, I imagine some people have hierarchical folders as
> > well, so it probably makes sense to store them as well.
> >
> > To do that, it's probably just a matter of calling gen_terms on the
> > complete filename. I haven't tested, but doing that should allow
> > Xapian's phrase searching to do the right thing for something like:
> >
> > filename:portion/of/the/path/name

I leave these two points for later since I do not have time for them now. If 
somebody want to do it, let me know.

Cheers
Michal

Re: [notmuch] [patch] store folder information

[Michal Sojka]

On Wednesday 27 of January 2010 16:55:55 micah anderson wrote:
> have not seen a reply from you yet. I'm particularly eager to see this
> get accepted upstream, and it sounds like the changes necessary to do so
> are relatively minor.

Hi Micah and others,

I wanted to test this patch, so I rebased it to the current HEAD. I had to do 
it manually since notmuch evolved significantly since the original posting. 
I'll post in followup mails.

> I'm wondering what your plans are for addressing these issues? I've come
> to depend on this functionality, and would love to see it incorporated
> upstream!
> 
> Specifically these were:
> 
> 1. Unrelated whitespace:

Fixed.
 
> 2. An unrelated hunk creeping in:
> 
> On Tue, 15 Dec 2009 13:22:19 -0800, Carl Worth  wrote:
> > On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl=C3=B6ckner
> >  
> tiker.net> wrote:
> > > @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
> > >   s++;
> > >   if (strncasecmp (s, "re:", 3) =3D=3D 0)
> > >   s +=3D 3;
> > > +else if (strncasecmp (s, "aw:", 3) =3D=3D 0)
> > > + s +=3D 3;
> > >   else
> > >   break;
> > >  }

Fixed.

> 3. Redundant trailing directory name traversal:
> > > +gchar *full_folder_name =3D NULL;
> > > +gchar *folder_base_name =3D NULL;
> > > +
> > > +/* Find name of "folder" containing the email. */
> > > +full_folder_name =3D g_strdup(path);
> > > +while (1)
> > > +{
> > > +folder_base_name =3D g_path_get_basename(full_folder_name);
> >
> > The trailing directory name is available already during the
> > traversal. So you don't need to search it back out again. See the patch
> > in the following message:
> >
> > id:87fx8bygi7@linux.vnet.ibm.com
> >
> > which simply passes the trailing directory name along, (but skipping a
> > name of "cur" or "new" while traversing).
> 
> 4. supporting hierarchical folders (perhaps this is a later improvement
> 
> that does not need to be added before the original patch is accepted?):
> > Beyond that, though, I imagine some people have hierarchical folders as
> > well, so it probably makes sense to store them as well.
> >
> > To do that, it's probably just a matter of calling gen_terms on the
> > complete filename. I haven't tested, but doing that should allow
> > Xapian's phrase searching to do the right thing for something like:
> >
> > filename:portion/of/the/path/name

I leave these two points for later since I do not have time for them now. If 
somebody want to do it, let me know.

Cheers
Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [patch] store folder information

[micah anderson]

Hi Andreas,

I'm just writing because of the patch you sent to the notmuch list on
December 15th. It seems like many people are wanting this functionality,
I know I am myself and Carl has also indicated the same. However, there
were a couple of minor suggestions for improvements for your patch that
have not seen a reply from you yet. I'm particularly eager to see this
get accepted upstream, and it sounds like the changes necessary to do so
are relatively minor.

I'm wondering what your plans are for addressing these issues? I've come
to depend on this functionality, and would love to see it incorporated
upstream! 

Specifically these were:

1. Unrelated whitespace:

On December 16th,2009 Ruben Pollan  wrote:

> [meskio at blackspot:src/notmuch.orig]$ git apply 
> ~/0001-Preseve-folder-information-when-indexing.patch
> /home/meskio/0001-Preseve-folder-information-when-indexing.patch:136: 
> trailing whitespace.
>status notmuch_database_add_message (notmuch, next,
> /home/meskio/0001-Preseve-folder-information-when-indexing.patch:137: 
> trailing whitespace.
>   folder_base_name,
> warning: 2 lines add whitespace errors.
>
> It's just whitespaces at the end of the lines.

2. An unrelated hunk creeping in:

On Tue, 15 Dec 2009 13:22:19 -0800, Carl Worth  wrote:
> On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl=C3=B6ckner  wrote:
> >
> > @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
> > s++;
> > if (strncasecmp (s, "re:", 3) =3D=3D 0)
> > s +=3D 3;
> > +else if (strncasecmp (s, "aw:", 3) =3D=3D 0)
> > +   s +=3D 3;
> > else
> > break;
> >  }
>=20
> This hunk looks unrelated to the rest. Could you submit that separately,
> please?


3. Redundant trailing directory name traversal:

> > +gchar *full_folder_name =3D NULL;
> > +gchar *folder_base_name =3D NULL;
> > +
> > +/* Find name of "folder" containing the email. */
> > +full_folder_name =3D g_strdup(path);
> > +while (1)
> > +{
> > +folder_base_name =3D g_path_get_basename(full_folder_name);
>
> The trailing directory name is available already during the
> traversal. So you don't need to search it back out again. See the patch
> in the following message:
>
>   id:87fx8bygi7.fsf at linux.vnet.ibm.com
>
> which simply passes the trailing directory name along, (but skipping a
> name of "cur" or "new" while traversing).

4. supporting hierarchical folders (perhaps this is a later improvement
that does not need to be added before the original patch is accepted?):

> Beyond that, though, I imagine some people have hierarchical folders as
> well, so it probably makes sense to store them as well.
>
> To do that, it's probably just a matter of calling gen_terms on the
> complete filename. I haven't tested, but doing that should allow
> Xapian's phrase searching to do the right thing for something like:
>
>   filename:portion/of/the/path/name

5. Probably the patch needs to be rebased off of master at this point.

Micah
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [notmuch] [patch] store folder information

[micah anderson]

Hi Andreas,

I'm just writing because of the patch you sent to the notmuch list on
December 15th. It seems like many people are wanting this functionality,
I know I am myself and Carl has also indicated the same. However, there
were a couple of minor suggestions for improvements for your patch that
have not seen a reply from you yet. I'm particularly eager to see this
get accepted upstream, and it sounds like the changes necessary to do so
are relatively minor.

I'm wondering what your plans are for addressing these issues? I've come
to depend on this functionality, and would love to see it incorporated
upstream! 

Specifically these were:

1. Unrelated whitespace:

On December 16th,2009 Ruben Pollan  wrote:

> [mes...@blackspot:src/notmuch.orig]$ git apply 
> ~/0001-Preseve-folder-information-when-indexing.patch
> /home/meskio/0001-Preseve-folder-information-when-indexing.patch:136: 
> trailing whitespace.
>status notmuch_database_add_message (notmuch, next,
> /home/meskio/0001-Preseve-folder-information-when-indexing.patch:137: 
> trailing whitespace.
>   folder_base_name,
> warning: 2 lines add whitespace errors.
>
> It's just whitespaces at the end of the lines.

2. An unrelated hunk creeping in:

On Tue, 15 Dec 2009 13:22:19 -0800, Carl Worth  wrote:
> On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl=C3=B6ckner  wrote:
> >
> > @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
> > s++;
> > if (strncasecmp (s, "re:", 3) =3D=3D 0)
> > s +=3D 3;
> > +else if (strncasecmp (s, "aw:", 3) =3D=3D 0)
> > +   s +=3D 3;
> > else
> > break;
> >  }
>=20
> This hunk looks unrelated to the rest. Could you submit that separately,
> please?


3. Redundant trailing directory name traversal:

> > +gchar *full_folder_name =3D NULL;
> > +gchar *folder_base_name =3D NULL;
> > +
> > +/* Find name of "folder" containing the email. */
> > +full_folder_name =3D g_strdup(path);
> > +while (1)
> > +{
> > +folder_base_name =3D g_path_get_basename(full_folder_name);
>
> The trailing directory name is available already during the
> traversal. So you don't need to search it back out again. See the patch
> in the following message:
>
>   id:87fx8bygi7@linux.vnet.ibm.com
>
> which simply passes the trailing directory name along, (but skipping a
> name of "cur" or "new" while traversing).

4. supporting hierarchical folders (perhaps this is a later improvement
that does not need to be added before the original patch is accepted?):

> Beyond that, though, I imagine some people have hierarchical folders as
> well, so it probably makes sense to store them as well.
>
> To do that, it's probably just a matter of calling gen_terms on the
> complete filename. I haven't tested, but doing that should allow
> Xapian's phrase searching to do the right thing for something like:
>
>   filename:portion/of/the/path/name

5. Probably the patch needs to be rebased off of master at this point.

Micah


pgpA2MoNAVnNu.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [patch] store folder information

[Marten Veldthuis]

On Tue, 15 Dec 2009 13:16:35 +0100, Ruben Pollan  
wrote:
> The patch works fine for me. I like it handles nicely the .foo.bar 
> directories 
> so I can do searches for "folder:foo" and for "folder:bar".
> 
> Reviewed-by: Ruben Pollan 

Second that, and I actually think it's a nicer solution than
automatically adding tags based on folder.

Reviewed-by: Marten Veldthuis 

-- 
- Marten

Re: [notmuch] [patch] store folder information

[Carl Worth]

On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Klöckner  
wrote:
> I've patched notmuch to retain information on which folder emails are stored 
> in. This makes the transition from a folders-and-procmail model somewhat 
> easier. The resulting changes are attached.

Very nice. I like this idea very much.

(We recently had discussions about automatically adding tags based on
the directories in which mail files were found, and I said I'd prefer a
solution which allowed the user to search on the directory name
instead.)

> @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
>   s++;
>   if (strncasecmp (s, "re:", 3) == 0)
>   s += 3;
> +else if (strncasecmp (s, "aw:", 3) == 0)
> + s += 3;
>   else
>   break;
>  }

This hunk looks unrelated to the rest. Could you submit that separately,
please?

> +gchar *full_folder_name = NULL;
> +gchar *folder_base_name = NULL;
> +
> +/* Find name of "folder" containing the email. */
> +full_folder_name = g_strdup(path);
> +while (1)
> +{
> +folder_base_name = g_path_get_basename(full_folder_name);

The trailing directory name is available already during the
traversal. So you don't need to search it back out again. See the patch
in the following message:

id:87fx8bygi7@linux.vnet.ibm.com

which simply passes the trailing directory name along, (but skipping a
name of "cur" or "new" while traversing).

That kind of approach looks a lot nice to me.

Beyond that, though, I imagine some people have hierarchical folders as
well, so it probably makes sense to store them as well.

To do that, it's probably just a matter of calling gen_terms on the
complete filename. I haven't tested, but doing that should allow
Xapian's phrase searching to do the right thing for something like:

filename:portion/of/the/path/name

I think something like that is what I would like to see.

-Carl


pgpR1SeBV6qMp.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [patch] store folder information

[Carl Worth]

On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl?ckner  wrote:
> I've patched notmuch to retain information on which folder emails are stored 
> in. This makes the transition from a folders-and-procmail model somewhat 
> easier. The resulting changes are attached.

Very nice. I like this idea very much.

(We recently had discussions about automatically adding tags based on
the directories in which mail files were found, and I said I'd prefer a
solution which allowed the user to search on the directory name
instead.)

> @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
>   s++;
>   if (strncasecmp (s, "re:", 3) == 0)
>   s += 3;
> +else if (strncasecmp (s, "aw:", 3) == 0)
> + s += 3;
>   else
>   break;
>  }

This hunk looks unrelated to the rest. Could you submit that separately,
please?

> +gchar *full_folder_name = NULL;
> +gchar *folder_base_name = NULL;
> +
> +/* Find name of "folder" containing the email. */
> +full_folder_name = g_strdup(path);
> +while (1)
> +{
> +folder_base_name = g_path_get_basename(full_folder_name);

The trailing directory name is available already during the
traversal. So you don't need to search it back out again. See the patch
in the following message:

id:87fx8bygi7.fsf at linux.vnet.ibm.com

which simply passes the trailing directory name along, (but skipping a
name of "cur" or "new" while traversing).

That kind of approach looks a lot nice to me.

Beyond that, though, I imagine some people have hierarchical folders as
well, so it probably makes sense to store them as well.

To do that, it's probably just a matter of calling gen_terms on the
complete filename. I haven't tested, but doing that should allow
Xapian's phrase searching to do the right thing for something like:

filename:portion/of/the/path/name

I think something like that is what I would like to see.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[notmuch] [patch] store folder information

[Ruben Pollan]

Some errors applying the patch:

[meskio at blackspot:src/notmuch.orig]$ git apply 
~/0001-Preseve-folder-information-when-indexing.patch
/home/meskio/0001-Preseve-folder-information-when-indexing.patch:136: trailing 
whitespace.
status = notmuch_database_add_message (notmuch, next, 
/home/meskio/0001-Preseve-folder-information-when-indexing.patch:137: trailing 
whitespace.
   folder_base_name, 
warning: 2 lines add whitespace errors.

It's just whitespaces at the end of the lines.


The patch works fine for me. I like it handles nicely the .foo.bar directories 
so I can do searches for "folder:foo" and for "folder:bar".

Reviewed-by: Ruben Pollan 

On 14:21, Mon 14 Dec 09, Andreas Kl?ckner wrote:
> I've patched notmuch to retain information on which folder emails are stored 
> in. This makes the transition from a folders-and-procmail model somewhat 
> easier. The resulting changes are attached.

-- 
Rub?n Poll?n  | jabber:meskio at jabber.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Lo que pasa es que tienes envidia
por que las vocecitas me hablan a mi.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: 

Re: [notmuch] [patch] store folder information

[Marten Veldthuis]

On Tue, 15 Dec 2009 13:16:35 +0100, Ruben Pollan  wrote:
> The patch works fine for me. I like it handles nicely the .foo.bar 
> directories 
> so I can do searches for "folder:foo" and for "folder:bar".
> 
> Reviewed-by: Ruben Pollan 

Second that, and I actually think it's a nicer solution than
automatically adding tags based on folder.

Reviewed-by: Marten Veldthuis 

-- 
- Marten
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [patch] store folder information

[Ruben Pollan]

Some errors applying the patch:

[mes...@blackspot:src/notmuch.orig]$ git apply 
~/0001-Preseve-folder-information-when-indexing.patch
/home/meskio/0001-Preseve-folder-information-when-indexing.patch:136: trailing 
whitespace.
status = notmuch_database_add_message (notmuch, next, 
/home/meskio/0001-Preseve-folder-information-when-indexing.patch:137: trailing 
whitespace.
   folder_base_name, 
warning: 2 lines add whitespace errors.

It's just whitespaces at the end of the lines.


The patch works fine for me. I like it handles nicely the .foo.bar directories 
so I can do searches for "folder:foo" and for "folder:bar".

Reviewed-by: Ruben Pollan 

On 14:21, Mon 14 Dec 09, Andreas Klöckner wrote:
> I've patched notmuch to retain information on which folder emails are stored 
> in. This makes the transition from a folders-and-procmail model somewhat 
> easier. The resulting changes are attached.

-- 
Rubén Pollán  | jabber:mes...@jabber.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Lo que pasa es que tienes envidia
por que las vocecitas me hablan a mi.


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [patch] store folder information

[Andreas Klöckner]

Hi there,

I've patched notmuch to retain information on which folder emails are stored 
in. This makes the transition from a folders-and-procmail model somewhat 
easier. The resulting changes are attached.

Andreas
From 179af7f436d8c21bad90e7eb88fc17c56f83c26c Mon Sep 17 00:00:00 2001
From: Andreas Kloeckner 
Date: Mon, 14 Dec 2009 14:16:20 -0500
Subject: [PATCH] Preseve folder information when indexing.

---
 lib/database.cc |   14 +-
 lib/index.cc|2 ++
 lib/notmuch.h   |1 +
 notmuch-new.c   |   35 ++-
 4 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index b6c4d07..e6b4272 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -70,10 +70,9 @@ typedef struct {
  *
  *	MESSAGE_ID:	The unique ID of the mail mess (see "id" above)
  *
- * In addition, terms from the content of the message are added with
- * "from", "to", "attachment", and "subject" prefixes for use by the
- * user in searching. But the database doesn't really care itself
- * about any of these.
+ * In addition, terms from the content of the message are added with "from",
+ * "to", "attachment", "subject", and "folder" prefixes for use by the user in
+ * searching. But the database doesn't really care itself about any of these.
  *
  * Timestamp document
  * --
@@ -124,7 +123,8 @@ prefix_t PROBABILISTIC_PREFIX[]= {
 { "from", "XFROM" },
 { "to", "XTO" },
 { "attachment", "XATTACHMENT" },
-{ "subject", "XSUBJECT"}
+{ "subject", "XSUBJECT"},
+{ "folder", "XFOLDER"}
 };
 
 int
@@ -889,6 +889,7 @@ _notmuch_database_link_message (notmuch_database_t *notmuch,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *notmuch,
 			  const char *filename,
+			  const char *folder_name,
 			  notmuch_message_t **message_ret)
 {
 notmuch_message_file_t *message_file;
@@ -1006,6 +1007,9 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
 
 	_notmuch_message_index_file (message, filename);
 
+if (folder_name != NULL)
+_notmuch_message_gen_terms (message, "folder", folder_name);
+
 	_notmuch_message_sync (message);
 } catch (const Xapian::Error &error) {
 	fprintf (stderr, "A Xapian exception occurred adding message: %s.\n",
diff --git a/lib/index.cc b/lib/index.cc
index 125fa6c..55f3fbc 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
 	s++;
 	if (strncasecmp (s, "re:", 3) == 0)
 	s += 3;
+else if (strncasecmp (s, "aw:", 3) == 0)
+	s += 3;
 	else
 	break;
 }
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 60834fb..5d3b3c6 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -265,6 +265,7 @@ notmuch_database_get_timestamp (notmuch_database_t *database,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *database,
 			  const char *filename,
+			  const char *folder_name,
 			  notmuch_message_t **message);
 
 /* Find a message with the given message_id.
diff --git a/notmuch-new.c b/notmuch-new.c
index 9d20616..bc8adc8 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,7 @@
 #include "notmuch-client.h"
 
 #include 
+#include 
 
 static volatile sig_atomic_t do_add_files_print_progress = 0;
 
@@ -144,6 +145,34 @@ add_files_recursive (notmuch_database_t *notmuch,
 struct dirent **namelist = NULL;
 int num_entries;
 
+gchar *full_folder_name = NULL;
+gchar *folder_base_name = NULL;
+
+/* Find name of "folder" containing the email. */
+full_folder_name = g_strdup(path);
+while (1)
+{
+folder_base_name = g_path_get_basename(full_folder_name);
+
+if (strcmp(folder_base_name, "cur") == 0
+|| strcmp(folder_base_name, "new") == 0)
+{
+gchar *parent_name = g_path_get_dirname(full_folder_name);
+g_free(full_folder_name);
+full_folder_name = parent_name;
+}
+else
+break;
+}
+
+g_free(full_folder_name);
+
+if (strcmp(folder_base_name, ".") == 0)
+{
+g_free(folder_base_name);
+folder_base_name = NULL;
+}
+
 /* If we're told to, we bail out on encountering a read-only
  * directory, (with this being a clear clue from the user to
  * Notmuch that new mail won't be arriving there and we need not
@@ -235,7 +264,9 @@ add_files_recursive (notmuch_database_t *notmuch,
 		fflush (stdout);
 		}
 
-		status = notmuch_database_add_message (notmuch, next, &message);
+		status = notmuch_database_add_message (notmuch, next, 
+   folder_base_name, 
+   &message);
 		switch (status) {
 		/* success */
 		case NOTMUCH_STATUS_SUCCESS:
@@ -301,6 +332,8 @@ add_files_recursive (notmuch_database_t *notmuch,
 	closedir (dir);
 if (namelist)
 	free (namelist);
+if (folder

[notmuch] [patch] store folder information

[Andreas Klöckner]

Hi there,

I've patched notmuch to retain information on which folder emails are stored 
in. This makes the transition from a folders-and-procmail model somewhat 
easier. The resulting changes are attached.

Andreas
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Preseve-folder-information-when-indexing.patch
Type: text/x-patch
Size: 4899 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: