date:20100202

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] [PATCH] Enforce foldmethod=manual when showing messages in vim

2010-02-02 Thread martin f. krafft

Vim's NotMuch mode relies on manual markers when rendering/showing
a message. If foldmethod is set to something else (marker in my case) by
default, then there are numerous errors, and folds don't work. Hence,
set foldmethod=manual for the local buffer upon showing a message.

Signed-off-by: martin f. krafft 
---
 vim/plugin/notmuch.vim |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index a226f20..2f9b05c 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -421,6 +421,7 @@ function! s:NM_cmd_show(words)
 let b:nm_raw_info = info
 let b:nm_prev_bufnr = prev_bufnr

+setlocal foldmethod=manual
 call NM_cmd_show_mkfolds()
 call NM_cmd_show_mksyntax()
 call NM_set_map('n', g:notmuch_show_maps)
-- 
1.6.6

[notmuch] [PATCHv2] Preserve folder information when indexing

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

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

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.

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] [PATCHv2] Preserve folder information when indexing

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: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100202/2278f688/attachment.pgp>

[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: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100202/fdcfbb58/attachment.pgp>

[notmuch] [PATCHv2] Preserve folder information when indexing

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, &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-in

[notmuch] Request for high-priority improvements to notmuch

2010-02-02 Thread martin f krafft

also sprach Scott Robinson  [2010.02.02.1043 +1300]:
> > YES PLEASE :-). notmuch seems designed to work in an ecosystem of
> > surrounding scripts, feeding data in and out. But we are all currently
> > limited to regexes for that. And heck, I hard a hard time understanding
> > why all hell broke out until I found that i had added a tag containing
> > parentheses which made my regex fail. :-). XML, JSON, any structured
> > output would be nice.
> > 
> > And as for filtering: YES, PLEASE :-). notmuchsync and many other 3rd
> > party apps would love that. As father of notmuchsync, I can tell you my
> > little script hickups very badly when slurping in 200k mails (including
> > text bodies) just to find out the maildir tags of those mails.
> > 
> 
> There's been a JSON patch waiting for a month now.

The last month has been busy for everyone, mainly due to LCA. We
should now all work together to help Carl go through the patch
queue. Maybe http://patchwork.madduck.net can help.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

beauty, brains, availability, personality; pick any two.

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100202/0cc7ca7c/attachment.pgp>

[notmuch] Request for high-priority improvements to notmuch

2010-02-02 Thread martin f krafft

also sprach sebastian at sspaeth.de  [2010.02.02.0929 
+1300]:
> YES PLEASE :-). notmuch seems designed to work in an ecosystem of
> surrounding scripts, feeding data in and out. But we are all currently
> limited to regexes for that. And heck, I hard a hard time understanding
> why all hell broke out until I found that i had added a tag containing
> parentheses which made my regex fail. :-). XML, JSON, any structured
> output would be nice.

Shoot me, but I'd say mbox output would be nice too.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"time flies like an arrow. fruit flies like a banana."
   -- groucho marx

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100202/fd712c86/attachment.pgp>

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

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.


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

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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [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.m...@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

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

[notmuch] [PATCHv2] Preserve folder information when indexing

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: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100202/c2b2d89d/attachment.pgp>

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

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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] patchwork test instance (was: Git feature branch)

2010-02-02 Thread Marten Veldthuis

On Tue, 2 Feb 2010 11:31:12 +1300, martin f krafft  
wrote:
> Arguably, being patch-centric means that a project has a higher
> barrier of entry, but it also means that if someone wants something,
> they know that they'll have to somehow end up with a patch. The way
> this happens on Git is that you either write it yourself and bring
> it up to discussion (which is what patchwork facilitates), or
> constructively theorise the functionality until someone else
> submits a patch.

And don't forget, if you really want something on the longterm todo
list, you can always send in a patch for the TODO file. ;)

-- 
- Marten

[notmuch] [PATCHv2] Preserve folder information when indexing

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: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100202/6470772f/attachment.pgp>

[notmuch] patchwork test instance (was: Git feature branch)

2010-02-02 Thread martin f krafft

I investigated some patch/issue trackers over the weekend. Here's my
summary/reply.

The executive summary is that
http://patchwork.madduck.net/project/notmuch/list/ now exists.
I have not really used it for anything real, so if some of you feel
inclined to give it a shot, sign up and triage away! Feedback
welcome.

also sprach James Rowe  [2010.01.28.2005 +1300]:
>   Roundup has command line and email interfaces.  The email interface is
> quite similar to debian's.  I've never used a launchpad hosted project
> so I can't compare it.

Roundup is an issue tracker, while Patchwork is a patch tracker.
They are fundamentally distinct, but there are overlaps. What led me
to go the Patchwork-path is that projects like the kernel and Git
don't use issue trackers but work entirely patch-based.

I don't know if that is the right way to do things, but having an
issue tracker that fills up with bugs and wishlist items lacking
patches is no better in the long run than not having an issue
tracker.

Arguably, being patch-centric means that a project has a higher
barrier of entry, but it also means that if someone wants something,
they know that they'll have to somehow end up with a patch. The way
this happens on Git is that you either write it yourself and bring
it up to discussion (which is what patchwork facilitates), or
constructively theorise the functionality until someone else
submits a patch.

>   Google's codereview tool has a nice interface for collecting and
> commenting on patches, but I suspect that suggestion will also meet with
> a degree of friction.  To me codereview feels like patchwork with
> polish.

Maybe you could take some ideas from codereview and inform the
patchwork people about them?

>   Both gitorious and github have commenting functionality built in.
> Commenting on commits in a fork is as easy as opening the commit in
> a browser.  I use something along the lines of the following script to
> open commits on github:
> 
> #! /bin/sh
> BASE=$(git config remote.${2:-origin}.url | sed 
> 's,git\(@\|://\)\([^:/]*\)[:/]\(.*\).git,http://\2/\3/commit,')
> COMMIT=$(git rev-parse ${1:-HEAD})
> sensible-browser ${BASE}/${COMMIT}
> 
>   Using github or gitorious you can easily find and track forks from one
> place as well, which makes discovering new work much easier.  Github
> even provides a pretty single page interface to the work going on in
> other forks, gitorious requires a little more leg work to do the same
> but not much.

Git now has commit notes, but it doesn't seem like that's integrated
with Github/Gitorious.

Mind you, patchwork isn't integrated at all with Git. It should be
possible to set it up to automatically flag patches that are
accepted into mainline, next, or pu.

The benefit of patchwork is that discussion isn't moved to the web,
but patchwork hooks into the mailing list, so discussion can stay
where it should IMHO be.

>   For a couple of hosted projects we use at the office we email the
> individual entries from http://github.com/$user/$project/comments.atom
> to the mailing list so they're /forcibly/ seen by everybody :)

Right, but replying requires them to open a browser and be online at
the time, right?



Anyway, I suggest we give patchwork a try. It occurs to me that
notmuch can pretty much do all of what patchwork is doing ? after
all, it's just tagging patches/threads, but until we have
synchronisable tags and a mailing list archive based on notmuch
(which could then replace patchwork), I think we'll need to employ
a third tool.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"what's your conceptual continuity? --
 well, it should be easy to see:
 the crux of the bisquit is the apopstrophe!"
-- frank zappa

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100202/a088f23e/attachment.pgp>

[notmuch] [PATCHv2] Preserve folder information when indexing

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: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100202/fd66d151/attachment.pgp>

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

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 mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

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.

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

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.


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

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.

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

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@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

[notmuch] [PATCHv2] Preserve folder information when indexing