Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
2010/1/28 martin f krafft madd...@madduck.net: also sprach Jameson Rollins jroll...@finestructure.net [2010.01.26.1046 +1300]: For example, I might have: ~/.notmuch-config: [database] path=/home/pioto/mail ... [tags] pi...@pioto.org/INBOX.ListMail.notmuch = notmuch So, a 'tags' section, where each key is the folder name, relative to the db path, and the value is one or more tag names I think this idea is a really good one and I would like to pursue it as a tangent thread here. I was going to propose something very similar to this. I think it's a very flexible idea that would help in a lot of ways. I think we need to carefully distinguish here. The above seems to suggest a mapping from folder to tag, but we don't actually need tags for folder locations because those can (and should) be implicitly determined from the database I think that the usefulness of this functionality is that we can have a mapping from physical organization of the mail to a tagging scheme of our choosing, and we can be relieved from having to remember the location of the mail (that can be different in different from different mail clients). But even right now I can't find a documented way of searching by location, so AFAIK the implementation of this proposal would allow something that is not possible at the moment. [tags] inbox = +inbox,+unread sent = +sent drafts = +draft archive = -inbox This proposal, on the other hand, is an interesting one, but when is it supposed to happen? It just feels wrong to make this happen as part of 'notmuch new'. Why so? What I would like to see is a notmuch-aware MDA, e.g. a programme which reads an incoming mail on stdin and can do all this kind of stuff, e.g. assign tags based on such rules (or take tags as arguments, so that I could trivially set tags from procmail too), write the message to the message store, and update the database. Such an MDA wouldn't need to use notmuch new, and thus won't be affected by this This would allow us to get rid of 'notmuch new' altogether, at least conceptually. We'd still need it if mail is being delivered independently, e.g. with offlineimap. Then we'd still need it, why not make it better? Regards, Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
also sprach Servilio Afre Puentes servi...@gmail.com [2010.01.29.0132 +1300]: [tags] inbox = +inbox,+unread sent = +sent drafts = +draft archive = -inbox This proposal, on the other hand, is an interesting one, but when is it supposed to happen? It just feels wrong to make this happen as part of 'notmuch new'. Why so? I guess I just dislike having to run notmuch new regularly, rather than integrating the database more closely with the mail flow. -- martin | http://madduck.net/ | http://two.sentenc.es/ to get back my youth i would do anything in the world, except take exercise, get up early, or be respectable. -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
Excerpts from martin f krafft's message of Thu Jan 28 15:39:10 -0500 2010: also sprach Servilio Afre Puentes servi...@gmail.com [2010.01.29.0132 +1300]: [tags] inbox = +inbox,+unread sent = +sent drafts = +draft archive = -inbox This proposal, on the other hand, is an interesting one, but when is it supposed to happen? It just feels wrong to make this happen as part of 'notmuch new'. Why so? I guess I just dislike having to run notmuch new regularly, rather than integrating the database more closely with the mail flow. Sounds like you need to add a line to crontab. - Ben ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
On Thu, 28 Jan 2010 15:49:34 -0500, Ben Gamari bgam...@gmail.com wrote: Sounds like you need to add a line to crontab. I haven't been following this thread closely so I hope this isn't too out of context. I agree that certain things like notmuch-new should go in the crontab, but I think that notmuch-new should need to be run exactly once to process a new batch of messages into the desired state. Having notmuch-new apply one set of tags and then relying on another process run afterwards to change the tags according to a filter is undesirable in my opinion, both for the mild performance reason of making two passes, but more importantly because of lock contention between the two processes and the ease of viewing the database in the inconsistent state. As far as I understand the situation, my favorite solution is to have notmuch-new run a hook on each message as it is indexed. Jed ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
also sprach Jameson Rollins jroll...@finestructure.net [2010.01.26.1046 +1300]: For example, I might have: ~/.notmuch-config: [database] path=/home/pioto/mail ... [tags] pi...@pioto.org/INBOX.ListMail.notmuch = notmuch So, a 'tags' section, where each key is the folder name, relative to the db path, and the value is one or more tag names I think this idea is a really good one and I would like to pursue it as a tangent thread here. I was going to propose something very similar to this. I think it's a very flexible idea that would help in a lot of ways. I think we need to carefully distinguish here. The above seems to suggest a mapping from folder to tag, but we don't actually need tags for folder locations, because those can (and should) be implicitly determined from the database and storing the tag in addition would just run the risk of getting out of sync: if I moved a message, I would also have to remember to delete old and add new tags, which is just asking for trouble. [tags] inbox = +inbox,+unread sent = +sent drafts = +draft archive = -inbox This proposal, on the other hand, is an interesting one, but when is it supposed to happen? It just feels wrong to make this happen as part of 'notmuch new'. What I would like to see is a notmuch-aware MDA, e.g. a programme which reads an incoming mail on stdin and can do all this kind of stuff, e.g. assign tags based on such rules (or take tags as arguments, so that I could trivially set tags from procmail too), write the message to the message store, and update the database. This would allow us to get rid of 'notmuch new' altogether, at least conceptually. We'd still need it if mail is being delivered independently, e.g. with offlineimap. On the performance side, it might make sense to write to a journal instead of updating the database every time. SpamAssassin does this with its Bayesian database, and it only merges the journal every X updates (or when the user manually requests it). I am not sure whether this is possible with Xapian. On the other hand, I think notmuch needs to learn to journal anyway so that we can keep different instances in sync. -- martin | http://madduck.net/ | http://two.sentenc.es/ the only way to get rid of a temptation is to yield to it. -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
also sprach Jameson Rollins jroll...@finestructure.net [2010.01.27.0603 +1300]: This is getting involved. Maybe I'm missing something in this thread; but, why couldn't these complex and context-sensitive decisions be delegated to sub-processes? ala git hooks? I think this idea is completely independent of anything having to do with using git as a mail store. That's why I was trying to separate it into a separate thread. I think he meant notmuch hooks like you have hooks for Git too, e.g. thread:755741d13573c7642761d2a175cb146d -- martin | http://madduck.net/ | http://two.sentenc.es/ if i am occasionally a little overdressed, i make up for it by being always immensely over-educated. -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
On Thu, 28 Jan 2010 18:12:52 +1300, martin f krafft madd...@madduck.net wrote: also sprach Jameson Rollins jroll...@finestructure.net [2010.01.27.0603 +1300]: This is getting involved. Maybe I'm missing something in this thread; but, why couldn't these complex and context-sensitive decisions be delegated to sub-processes? ala git hooks? I think this idea is completely independent of anything having to do with using git as a mail store. That's why I was trying to separate it into a separate thread. I think he meant notmuch hooks like you have hooks for Git too, e.g. thread:755741d13573c7642761d2a175cb146d Are you trying to use thread: such that it could be passed to notmuch show to see the conversation? That's not going to work so well if so. Thanks, James ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
also sprach James Westby jw+deb...@jameswestby.net [2010.01.28.1828 +1300]: Are you trying to use thread: such that it could be passed to notmuch show to see the conversation? That's not going to work so well if so. Why not? Works fine for me with the vim plugin... -- martin | http://madduck.net/ | http://two.sentenc.es/ perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- antoine de saint-exupéry spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
On Thu, 28 Jan 2010 18:34:21 +1300, martin f krafft madd...@madduck.net wrote:
also sprach James Westby jw+deb...@jameswestby.net [2010.01.28.1828 +1300]:
Are you trying to use thread: such that it could be passed to
notmuch show to see the conversation?
That's not going to work so well if so.
Why not? Works fine for me with the vim plugin...
lib/message.cc:560
static void
thread_id_generate (thread_id_t *thread_id)
{
static int seeded = 0;
FILE *dev_random;
uint32_t value;
char *s;
int i;
if (! seeded) {
dev_random = fopen (/dev/random, r);
if (dev_random == NULL) {
srand (time (NULL));
} else {
fread ((void *) value, sizeof (value), 1, dev_random);
srand (value);
fclose (dev_random);
}
seeded = 1;
}
s = thread_id-str;
for (i = 0; i NOTMUCH_THREAD_ID_DIGITS; i += 8) {
value = rand ();
sprintf (s, %08x, value);
s += 8;
}
}
so it works fine for you, however I have no idea which thread you are
talking about.
Thanks,
James
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
Excerpts from Jameson Rollins's message of Mon Jan 25 15:46:55 -0600 2010: I think this idea is a really good one and I would like to pursue it as a tangent thread here. I was going to propose something very similar to this. I think it's a very flexible idea that would help in a lot of ways. [...] This is getting involved. Maybe I'm missing something in this thread; but, why couldn't these complex and context-sensitive decisions be delegated to sub-processes? ala git hooks? ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
