[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-03 Thread Sebastian Spaeth
On Tue, 2 Feb 2010 23:25:18 +0100, Michal Sojka  wrote:
> I want it to work the same way as you expected. It seems it would be 
> necessary 
> to modify notmuch_database_remove_message() so that it changes folder term if 
> it detects rename.

On a tangetial issue: It would help if notmuch were able to set an
(optional) flag when detecting a rename. Similar on how it should set
"new" on new messages, a "moved" tag or whatever would make parsing with
3rd party apps much nicer.

E.g. my folder-to-tag syncer could then just look for moved mails and my
MailDirflag-to-notmuchtag syncer could then limit its search also to
"moved" mails, which would be much more efficient.

What do people think?
Basically what I want is:

notmuch.conf:
tag-for-new="inbox unread notspamchecked whatnothere"
tag-for-moved="moved"

Does this make sense?

Sebastian


[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-03 Thread Sebastian Spaeth
> /media/mail/mail
> ??? cur
> ?   ??? 1265050537.H891745P1231.samir.ibcsolutions.de:2,S
> ?   ??? 1265050572.H419259P1443.samir.ibcsolutions.de:2,S
> ?   ??? 1265050598.H121639P1634.samir.ibcsolutions.de:2,S
> ?   ??? 1265050617.H309805P1774.samir.ibcsolutions.de:2,S
> ?   ??? 1265050625.H818906P1838.samir.ibcsolutions.de:2,S
> ?   ??? 1265050955.H593083P2020.samir.ibcsolutions.de:2,S

A related question, currently notmuch seems to store the full absolute
path to mails, but I remeber seeing some documentation saying that it's
either absolute or relative to the xapian db dir. Is that correct, or is
it reasonable to assume absolute directories (as e.g. notmuchsync
currently does).

Sebastian


Re: [notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-03 Thread Sebastian Spaeth
On Tue, 2 Feb 2010 23:25:18 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
 I want it to work the same way as you expected. It seems it would be 
 necessary 
 to modify notmuch_database_remove_message() so that it changes folder term if 
 it detects rename.

On a tangetial issue: It would help if notmuch were able to set an
(optional) flag when detecting a rename. Similar on how it should set
new on new messages, a moved tag or whatever would make parsing with
3rd party apps much nicer.

E.g. my folder-to-tag syncer could then just look for moved mails and my
MailDirflag-to-notmuchtag syncer could then limit its search also to
moved mails, which would be much more efficient.

What do people think?
Basically what I want is:

notmuch.conf:
tag-for-new=inbox unread notspamchecked whatnothere
tag-for-moved=moved

Does this make sense?

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


[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Michal Sojka
On Tuesday 02 February 2010 22:31:38 micah anderson wrote:
> On Tue, 02 Feb 2010 13:22:29 -0500, Jameson Rollins 
 wrote:
> > I'm starting to think that maybe the folder: field is not the right way
> > to do this, though.  What if a message moves?
> 
> The easiest way to answer this question is to try it. I did that, and
> things didn't work as expected. I expected that once the message was
> moved to a different folder, and 'notmuch new' was run, then the folder
> search result would move with the message move.

I want it to work the same way as you expected. It seems it would be necessary 
to modify notmuch_database_remove_message() so that it changes folder term if 
it detects rename.

I guess it should be possible. If tags can be modified then folder terms can 
be modified as well.

Michal


[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Michal Sojka
On Tuesday 02 February 2010 18:48:25 Arvid Picciani wrote:
> On Tue,  2 Feb 2010 16:01:08 +0100, Michal Sojka
> 
> wrote:
> > Stores the folder (directory name) of the message in the database as a
> > term with folder prefix.

Hi,

I've just made several experiments. I tested both Maildir layout (your case)
and non-Maildir layout and both layouts work correctly.

Then I tried to create notmuch database without this patch and then add new 
mails
and run notmuch new with the patch. It seems that in that case no folder terms
are added to the database. 

Probably DATABASE_VERSION should be increased by this patch, but I do not want
to do it until it is clear that this patch will be merged. Otherwise, there 
might be collision with other patches.
> 
> unfortunately it doesnt do anything here :/
> i rebuilt the entire index, but no folder: field is added.

How did you rebuild it? I deleted the .notmuch directory and run notmuch new.

> can anyone who got it working tell me their directory layout?
> mine would be something like:

If the above didn't help, try to apply this patch. If you see your folder names
during notmuch new, it should work.

Michal

 8< --
diff --git a/lib/database.cc b/lib/database.cc
index ba2aa16..a22e226 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1436,6 +1436,7 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
date = notmuch_message_file_get_header (message_file, "date");
_notmuch_message_set_date (message, date);

+   printf("folder=%s\n", folder_name);
if (folder_name != NULL)
_notmuch_message_gen_terms (message, "folder", folder_name);




[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Arvid Picciani

It's all the dots fault.   it works just fine with folders not beginning
with .

On Tue, 02 Feb 2010 13:22:29 -0500, Jameson Rollins  wrote:
> I'm going back to my original
> suggestion, which was that the configuration should state tag that
> should be added for messages in certain folders.

well that would be almost what i want. My folders are autogenerated by a
generic list filter, and i'd be to lazy to check regulary for new
folders.
But tags are the proper solution here imo.


[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Jameson Rollins
On Tue, 2 Feb 2010 23:25:18 +0100, Michal Sojka  wrote:
> On Tuesday 02 February 2010 22:31:38 micah anderson wrote:
> > The easiest way to answer this question is to try it. I did that, and
> > things didn't work as expected. I expected that once the message was
> > moved to a different folder, and 'notmuch new' was run, then the folder
> > search result would move with the message move.
> 
> I want it to work the same way as you expected. It seems it would be 
> necessary 
> to modify notmuch_database_remove_message() so that it changes folder term if 
> it detects rename.

Hey, Michal.  I agree that this is a necessary improvement.  It would
also be nice if messages that don't currently have the field have it
added, whether or not they're in the database to begin with.  This is
important for getting the field on messages that are already in the
database.

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



[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread micah anderson
On Tue, 02 Feb 2010 13:22:29 -0500, Jameson Rollins  wrote:
> I'm starting to think that maybe the folder: field is not the right way
> to do this, though.  What if a message moves?  

The easiest way to answer this question is to try it. I did that, and
things didn't work as expected. I expected that once the message was
moved to a different folder, and 'notmuch new' was run, then the folder
search result would move with the message move. 

I tried to move a message from folder 'thinkpad' to folder 'Junk':

1. First I did a search that included the thinkpad folder, with a string
I know is in an email:

$ notmuch search folder:thinkpad 05K9519
thread:4ba02e2c665b09fb74dc6f1b6ea3aac2   2004-02-25 [1/1] J H. Maut; RE: 
[Thinkpad] thinkpad 600e LCD quesiton (thinkpad unread)

2. then I moved that email to my Junk folder and ran notmuch new:

$ mv 
INBOX.thinkpad/new1147465172.M760586P11592V0301I00141D45_7229.um\,S\=2421\:2\,S
 INBOX.Junk/new
$ notmuch new
Processed 1 file in almost no time.
No new mail. Detected 1 file rename.

3. then I tried to repeat the search I did in #1, searching for the
folder thinkpad and the string, and it still returns the result (this is
not expected! I would expect no result returned):

$ notmuch search folder:thinkpad 05K9519
thread:4ba02e2c665b09fb74dc6f1b6ea3aac2   2004-02-25 [1/1] J H. Maut; RE: 
[Thinkpad] thinkpad 600e LCD quesiton (thinkpad unread)

4. If i try and search for the same message in the Junk folder, I get no
results:

$ notmuch search folder:Junk 05K9519
$ 

5. If I do a show on the message, I see that notmuch knows that the
file is actually in the Junk folder:

$ notmuch show thread:4ba02e2c665b09fb74dc6f1b6ea3aac2

message{ id:BKEJKEHBAJJAFLAGIHJCGCAA.J.H.Maut at somewhere.net depth:0 
match:1 
filename:/home/micah/Maildir/Personal/INBOX.Junk/new/1147465172.M760586P11592V0301I00141D45_7229.um,S=2421:2,S


> Only new mails are having this field modified, so if messages are
> moved that field is not modified, and since it's being added as part
> of the message (like "subject:") it's not modifiable.  

Exactly the problem.

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



[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Michal Sojka
Stores the folder (directory name) of the message in the database as a
term with folder prefix.

This patch was originally sent by Andreas Kl?ckner. The differences
from the original patch are:
- Folder name is taken from strings generated during travesal. It no
  longer uses glib nor it allocates additional memory to determine the
  base name. The same approach as in
  id:87fx8bygi7.fsf at linux.vnet.ibm.com was used.
- Removed unrelated change which was submitted separately as
  id:1264691584-8290-2-git-send-email-sojkam1 at fel.cvut.cz
- Changed the comment describing database schema.

TODO (see the previous Carl's email):
- Support hierarchical folders

---
 lib/database.cc |   17 -
 lib/notmuch.h   |1 +
 notmuch-new.c   |9 ++---
 3 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index cce7847..ba2aa16 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -83,10 +83,10 @@ 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 and path 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.
  *
  * The data portion of a mail document is empty.
  *
@@ -154,7 +154,10 @@ prefix_t PROBABILISTIC_PREFIX[]= {
 { "from",  "XFROM" },
 { "to","XTO" },
 { "attachment","XATTACHMENT" },
-{ "subject",   "XSUBJECT"}
+{ "subject",   "XSUBJECT"},
+{ "folder","XFOLDER"}
+// FIXME: Is folder realy a candidate for probabilistic prefix or
+// it should be a boolean prefix instead?
 };

 int
@@ -1317,6 +1320,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;
@@ -1432,6 +1436,9 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
date = notmuch_message_file_get_header (message_file, "date");
_notmuch_message_set_date (message, date);

+   if (folder_name != NULL)
+   _notmuch_message_gen_terms (message, "folder", folder_name);
+
_notmuch_message_index_file (message, filename);
} else {
ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 15c9db4..3a5ab78 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -263,6 +263,7 @@ notmuch_database_get_directory (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);

 /* Remove a message from the given notmuch database.
diff --git a/notmuch-new.c b/notmuch-new.c
index f25c71f..afd4e3d 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -207,6 +207,7 @@ _entries_resemble_maildir (struct dirent **entries, int 
count)
 static notmuch_status_t
 add_files_recursive (notmuch_database_t *notmuch,
 const char *path,
+const char *folder,
 add_files_state_t *state)
 {
 DIR *dir = NULL;
@@ -302,7 +303,9 @@ add_files_recursive (notmuch_database_t *notmuch,
}

next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);
-   status = add_files_recursive (notmuch, next, state);
+   status = add_files_recursive (notmuch, next,
+ is_maildir ? folder : entry->d_name,
+ state);
if (status && ret == NOTMUCH_STATUS_SUCCESS)
ret = status;
talloc_free (next);
@@ -407,7 +410,7 @@ add_files_recursive (notmuch_database_t *notmuch,
fflush (stdout);
}

-   status = notmuch_database_add_message (notmuch, next, );
+   status = notmuch_database_add_message (notmuch, next, folder, );
switch (status) {
/* success */
case NOTMUCH_STATUS_SUCCESS:
@@ -546,7 +549,7 @@ add_files (notmuch_database_t *notmuch,
return NOTMUCH_STATUS_FILE_ERROR;
 }

-status = add_files_recursive (notmuch, path, state);
+status = add_files_recursive (notmuch, path, basename(path), state);

 if (timer_is_active) {
/* Now stop the timer. */
-- 
tg: (a2d919e..) 

[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Jameson Rollins
On Tue, 02 Feb 2010 18:48:25 +0100, Arvid Picciani  wrote:
> On Tue,  2 Feb 2010 16:01:08 +0100, Michal Sojka 
> wrote:
> unfortunately it doesnt do anything here :/
> i rebuilt the entire index, but no folder: field is added.
> can anyone who got it working tell me their directory layout?
> mine would be something like:

What search terms are you using?  You shouldn't consider the cur/new/tmp
maildir subdirectories in the folder naming.  Those are fundamental
parts of maildirs.  You would want to look at the maildir name itself.

I'm starting to think that maybe the folder: field is not the right way
to do this, though.  What if a message moves?  Only new mails are having
this field modified, so if messages are moved that field is not
modified, and since it's being added as part of the message (like
"subject:") it's not modifiable.  It also can't be added down the line
to messages that don't already have it.  I'm going back to my original
suggestion, which was that the configuration should state tag that
should be added for messages in certain folders.

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



[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Jameson Rollins
On Tue, 02 Feb 2010 11:20:02 -0500, Jameson Rollins  wrote:
> I just gave it a try, though, and it seemed to be behaving a little
> strangely.  I currently have two subdirectories, "inbox" and "sent".
> However, new mail to either directory was showing up under the search:
> 
> notmuch search folder:inbox
> 
> and nothing was showing up under the search:
> 
> notmuch search folder:sent
> 
> I wonder if there's a problem with the logic it uses to determine the
> folder naming?  Do you think you could look into this?  I would really
> like to push to have a patch like this applied upstream soon.

I think I was wrong about this.  It looks like I'm seeing a different
issue that may not be related.  As a test I was sending mail to myself,
which meant that it was showing up in both "inbox" *and* "sent", and it
looks like in the face of an email in duplicate directories, the "inbox"
was winning.  Mail sent to not me is showing up under folder:sent just
fine.  So I think this is working!

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



[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Jameson Rollins
On Tue,  2 Feb 2010 16:01:08 +0100, Michal Sojka  wrote:
> Stores the folder (directory name) of the message in the database as a
> term with folder prefix.
> 
> This patch was originally sent by Andreas Kl?ckner. The differences
> from the original patch are:
> - Folder name is taken from strings generated during travesal. It no
>   longer uses glib nor it allocates additional memory to determine the
>   base name. The same approach as in
>   id:87fx8bygi7.fsf at linux.vnet.ibm.com was used.
> - Removed unrelated change which was submitted separately as
>   id:1264691584-8290-2-git-send-email-sojkam1 at fel.cvut.cz
> - Changed the comment describing database schema.
> 
> TODO (see the previous Carl's email):
> - Support hierarchical folders

Hey, Michal.  Thank you very much for this patch!  This is right on with
what I mentioned as high-priority improvements.

I just gave it a try, though, and it seemed to be behaving a little
strangely.  I currently have two subdirectories, "inbox" and "sent".
However, new mail to either directory was showing up under the search:

notmuch search folder:inbox

and nothing was showing up under the search:

notmuch search folder:sent

I wonder if there's a problem with the logic it uses to determine the
folder naming?  Do you think you could look into this?  I would really
like to push to have a patch like this applied upstream soon.

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



[notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Michal Sojka
Stores the folder (directory name) of the message in the database as a
term with folder prefix.

This patch was originally sent by Andreas Klöckner. The differences
from the original patch are:
- Folder name is taken from strings generated during travesal. It no
  longer uses glib nor it allocates additional memory to determine the
  base name. The same approach as in
  id:87fx8bygi7@linux.vnet.ibm.com was used.
- Removed unrelated change which was submitted separately as
  id:1264691584-8290-2-git-send-email-sojk...@fel.cvut.cz
- Changed the comment describing database schema.

TODO (see the previous Carl's email):
- Support hierarchical folders

---
 lib/database.cc |   17 -
 lib/notmuch.h   |1 +
 notmuch-new.c   |9 ++---
 3 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index cce7847..ba2aa16 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -83,10 +83,10 @@ 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 and path 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.
  *
  * The data portion of a mail document is empty.
  *
@@ -154,7 +154,10 @@ prefix_t PROBABILISTIC_PREFIX[]= {
 { from,  XFROM },
 { to,XTO },
 { attachment,XATTACHMENT },
-{ subject,   XSUBJECT}
+{ subject,   XSUBJECT},
+{ folder,XFOLDER}
+// FIXME: Is folder realy a candidate for probabilistic prefix or
+// it should be a boolean prefix instead?
 };
 
 int
@@ -1317,6 +1320,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;
@@ -1432,6 +1436,9 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
date = notmuch_message_file_get_header (message_file, date);
_notmuch_message_set_date (message, date);
 
+   if (folder_name != NULL)
+   _notmuch_message_gen_terms (message, folder, folder_name);
+
_notmuch_message_index_file (message, filename);
} else {
ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 15c9db4..3a5ab78 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -263,6 +263,7 @@ notmuch_database_get_directory (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);
 
 /* Remove a message from the given notmuch database.
diff --git a/notmuch-new.c b/notmuch-new.c
index f25c71f..afd4e3d 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -207,6 +207,7 @@ _entries_resemble_maildir (struct dirent **entries, int 
count)
 static notmuch_status_t
 add_files_recursive (notmuch_database_t *notmuch,
 const char *path,
+const char *folder,
 add_files_state_t *state)
 {
 DIR *dir = NULL;
@@ -302,7 +303,9 @@ add_files_recursive (notmuch_database_t *notmuch,
}
 
next = talloc_asprintf (notmuch, %s/%s, path, entry-d_name);
-   status = add_files_recursive (notmuch, next, state);
+   status = add_files_recursive (notmuch, next,
+ is_maildir ? folder : entry-d_name,
+ state);
if (status  ret == NOTMUCH_STATUS_SUCCESS)
ret = status;
talloc_free (next);
@@ -407,7 +410,7 @@ 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, message);
switch (status) {
/* success */
case NOTMUCH_STATUS_SUCCESS:
@@ -546,7 +549,7 @@ add_files (notmuch_database_t *notmuch,
return NOTMUCH_STATUS_FILE_ERROR;
 }
 
-status = add_files_recursive (notmuch, path, state);
+status = add_files_recursive (notmuch, path, basename(path), state);
 
 if (timer_is_active) {
/* Now stop the timer. */
-- 
tg: (a2d919e..) t/Preserve-folder-information-when-indexing (depends on: master)

Re: [notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Jameson Rollins
On Tue,  2 Feb 2010 16:01:08 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
 Stores the folder (directory name) of the message in the database as a
 term with folder prefix.
 
 This patch was originally sent by Andreas Klöckner. The differences
 from the original patch are:
 - Folder name is taken from strings generated during travesal. It no
   longer uses glib nor it allocates additional memory to determine the
   base name. The same approach as in
   id:87fx8bygi7@linux.vnet.ibm.com was used.
 - Removed unrelated change which was submitted separately as
   id:1264691584-8290-2-git-send-email-sojk...@fel.cvut.cz
 - Changed the comment describing database schema.
 
 TODO (see the previous Carl's email):
 - Support hierarchical folders

Hey, Michal.  Thank you very much for this patch!  This is right on with
what I mentioned as high-priority improvements.

I just gave it a try, though, and it seemed to be behaving a little
strangely.  I currently have two subdirectories, inbox and sent.
However, new mail to either directory was showing up under the search:

notmuch search folder:inbox

and nothing was showing up under the search:

notmuch search folder:sent

I wonder if there's a problem with the logic it uses to determine the
folder naming?  Do you think you could look into this?  I would really
like to push to have a patch like this applied upstream soon.

jamie.


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


Re: [notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Jameson Rollins
On Tue, 02 Feb 2010 11:20:02 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
 I just gave it a try, though, and it seemed to be behaving a little
 strangely.  I currently have two subdirectories, inbox and sent.
 However, new mail to either directory was showing up under the search:
 
 notmuch search folder:inbox
 
 and nothing was showing up under the search:
 
 notmuch search folder:sent
 
 I wonder if there's a problem with the logic it uses to determine the
 folder naming?  Do you think you could look into this?  I would really
 like to push to have a patch like this applied upstream soon.

I think I was wrong about this.  It looks like I'm seeing a different
issue that may not be related.  As a test I was sending mail to myself,
which meant that it was showing up in both inbox *and* sent, and it
looks like in the face of an email in duplicate directories, the inbox
was winning.  Mail sent to not me is showing up under folder:sent just
fine.  So I think this is working!

jamie.


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


Re: [notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Arvid Picciani
On Tue,  2 Feb 2010 16:01:08 +0100, Michal Sojkasojk...@fel.cvut.cz 
wrote:



Stores the folder (directory name) of the message in the database as a
term with folder prefix.


unfortunately it doesnt do anything here :/
i rebuilt the entire index, but no folder: field is added.
can anyone who got it working tell me their directory layout?
mine would be something like:

/media/mail/mail
├── cur
│   ├── 1265050537.H891745P1231.samir.ibcsolutions.de:2,S
│   ├── 1265050572.H419259P1443.samir.ibcsolutions.de:2,S
│   ├── 1265050598.H121639P1634.samir.ibcsolutions.de:2,S
│   ├── 1265050617.H309805P1774.samir.ibcsolutions.de:2,S
│   ├── 1265050625.H818906P1838.samir.ibcsolutions.de:2,S
│   ├── 1265050955.H593083P2020.samir.ibcsolutions.de:2,S

[...]
├── .list.bla
[...]
├── .list.foo
[...]
├── .list.unknown
│   ├── cur
│   │   └── 1265050581.H226772P1509.samir.ibcsolutions.de:2,
│   ├── dovecot.index.cache
│   ├── dovecot.index.log
│   ├── dovecot-uidlist
│   ├── new
│   └── tmp
├── new
├── .notmuch
│   └── xapian
│   ├── flintlock
│   ├── iamchert
│   ├── position.baseA
│   ├── position.baseB
│   ├── position.DB
│   ├── postlist.baseA
│   ├── postlist.baseB
│   ├── postlist.DB
│   ├── record.baseA
│   ├── record.baseB
│   ├── record.DB
│   ├── termlist.baseA
│   ├── termlist.baseB
│   └── termlist.DB
├── .Sent
│   ├── cur
│   │   ├── 1262650675.00.mbox:2,S
│   │   ├── 1262650675.01.mbox:2,S
│   │   ├── 1262650675.02.mbox:2,S

[...]
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Jameson Rollins
On Tue, 02 Feb 2010 18:48:25 +0100, Arvid Picciani a...@exys.org wrote:
 On Tue,  2 Feb 2010 16:01:08 +0100, Michal Sojkasojk...@fel.cvut.cz 
 wrote:
 unfortunately it doesnt do anything here :/
 i rebuilt the entire index, but no folder: field is added.
 can anyone who got it working tell me their directory layout?
 mine would be something like:

What search terms are you using?  You shouldn't consider the cur/new/tmp
maildir subdirectories in the folder naming.  Those are fundamental
parts of maildirs.  You would want to look at the maildir name itself.

I'm starting to think that maybe the folder: field is not the right way
to do this, though.  What if a message moves?  Only new mails are having
this field modified, so if messages are moved that field is not
modified, and since it's being added as part of the message (like
subject:) it's not modifiable.  It also can't be added down the line
to messages that don't already have it.  I'm going back to my original
suggestion, which was that the configuration should state tag that
should be added for messages in certain folders.

jamie.


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


Re: [notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Michal Sojka
On Tuesday 02 February 2010 18:48:25 Arvid Picciani wrote:
 On Tue,  2 Feb 2010 16:01:08 +0100, Michal Sojkasojk...@fel.cvut.cz
 
 wrote:
  Stores the folder (directory name) of the message in the database as a
  term with folder prefix.

Hi,

I've just made several experiments. I tested both Maildir layout (your case)
and non-Maildir layout and both layouts work correctly.

Then I tried to create notmuch database without this patch and then add new 
mails
and run notmuch new with the patch. It seems that in that case no folder terms
are added to the database. 

Probably DATABASE_VERSION should be increased by this patch, but I do not want
to do it until it is clear that this patch will be merged. Otherwise, there 
might be collision with other patches.
 
 unfortunately it doesnt do anything here :/
 i rebuilt the entire index, but no folder: field is added.

How did you rebuild it? I deleted the .notmuch directory and run notmuch new.

 can anyone who got it working tell me their directory layout?
 mine would be something like:

If the above didn't help, try to apply this patch. If you see your folder names
during notmuch new, it should work.

Michal

 8 --
diff --git a/lib/database.cc b/lib/database.cc
index ba2aa16..a22e226 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1436,6 +1436,7 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
date = notmuch_message_file_get_header (message_file, date);
_notmuch_message_set_date (message, date);
 
+   printf(folder=%s\n, folder_name);
if (folder_name != NULL)
_notmuch_message_gen_terms (message, folder, folder_name);
 

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


Re: [notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Michal Sojka
On Tuesday 02 February 2010 22:31:38 micah anderson wrote:
 On Tue, 02 Feb 2010 13:22:29 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
  I'm starting to think that maybe the folder: field is not the right way
  to do this, though.  What if a message moves?
 
 The easiest way to answer this question is to try it. I did that, and
 things didn't work as expected. I expected that once the message was
 moved to a different folder, and 'notmuch new' was run, then the folder
 search result would move with the message move.

I want it to work the same way as you expected. It seems it would be necessary 
to modify notmuch_database_remove_message() so that it changes folder term if 
it detects rename.

I guess it should be possible. If tags can be modified then folder terms can 
be modified as well.

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


Re: [notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Jameson Rollins
On Tue, 2 Feb 2010 23:25:18 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
 On Tuesday 02 February 2010 22:31:38 micah anderson wrote:
  The easiest way to answer this question is to try it. I did that, and
  things didn't work as expected. I expected that once the message was
  moved to a different folder, and 'notmuch new' was run, then the folder
  search result would move with the message move.
 
 I want it to work the same way as you expected. It seems it would be 
 necessary 
 to modify notmuch_database_remove_message() so that it changes folder term if 
 it detects rename.

Hey, Michal.  I agree that this is a necessary improvement.  It would
also be nice if messages that don't currently have the field have it
added, whether or not they're in the database to begin with.  This is
important for getting the field on messages that are already in the
database.

jamie.


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


Re: [notmuch] [PATCHv2] Preserve folder information when indexing

2010-02-02 Thread Sebastian Spaeth
 /media/mail/mail
 ├── cur
 │   ├── 1265050537.H891745P1231.samir.ibcsolutions.de:2,S
 │   ├── 1265050572.H419259P1443.samir.ibcsolutions.de:2,S
 │   ├── 1265050598.H121639P1634.samir.ibcsolutions.de:2,S
 │   ├── 1265050617.H309805P1774.samir.ibcsolutions.de:2,S
 │   ├── 1265050625.H818906P1838.samir.ibcsolutions.de:2,S
 │   ├── 1265050955.H593083P2020.samir.ibcsolutions.de:2,S

A related question, currently notmuch seems to store the full absolute
path to mails, but I remeber seeing some documentation saying that it's
either absolute or relative to the xapian db dir. Is that correct, or is
it reasonable to assume absolute directories (as e.g. notmuchsync
currently does).

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