[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[martin f krafft]

also sprach Ben Gamari  [2010.01.29.0949 +1300]:
> > 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.

It still feels like a hack. It's a bit like making many changes to
a source code repository (new mails get delivered) and committing
only once every hour (notmuch new), rather than making and
committing transactional changes (delivering and catalogueing mails
individually).

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

a Hooloovoo is a superintelligent shade of the color blue.
-- douglas adams, "the hitchhiker's guide to the galaxy"

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: 

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[martin f krafft]

also sprach martin f krafft  [2010.01.28.1834 +1300]:
> > That's not going to work so well if so.
> 
> Why not? Works fine for me with the vim plugin...

Now I get it. I was talking about
id:20100114084713.GA22273 at harikalardiyari

Sorry, I *am* new to notmuch ;)

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

"when zarathustra was alone... he said to his heart: 'could it be
 possible! this old saint in the forest hath not yet heard of it, that
 god is dead!'"
 - friedrich nietzsche

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: 

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[Jed Brown]

On Thu, 28 Jan 2010 15:49:34 -0500, Ben Gamari  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] tag dir proposal [was: Re: Git as notmuch object store]

[Ben Gamari]

Excerpts from martin f krafft's message of Thu Jan 28 17:17:35 -0500 2010:
> Cron-scheduling is a regular activity. I am talking about
> event-based scheduling. incron could do that and fire up a process
> every time a message is dropped into a directory, but notmuch
> doesn't provide me with an interface to say "you don't have to
> iterate the Maildir yourself since I know exactly what changed: just
> update your catalog with the new message in file foo/bar.msg".

Fair enough. After reading your arguments I think I might have initially
misunderstood you. I would actually tend to agree. Passing
paths to notmuch does seem to be a reasonable approach.

> 
> To me, notmuch-new is not Unix-y. To me,
> 
>   find $MAILDIR -type f -print0 | xargs -0 notmuch-update
> 
> is Unix-y. ;)
> 
I think it really depends upon what you are doing. I can certainly see
when you might be want to simply have notmuch synchronize the index
against the mail store. However, it seems the majority of the time one
simply desires to add a message to the index (i.e. after delivery).
Therefore, it seems like there is a place for both commands.

> > In my configuration, I simply have a bash script in ~/.bin that simply
> > runs offlineimap followed by notmuch new. This works quite nicely.
> 
> This is essentially the same situation as with slocate, which has to
> be run from cron currently, and hence gets outdated regularly.
> Compare this to a hypothetical filesystem that exposed an index of
> filenames (or content even!) to user-space, which could be used to
> quickly search for files in real-time without the need to run
> regular updates. I know other operating systems that have this
> functionality already.
> 
> Anyway, this is going off on a tangent, I feel.
> 
That might be true but that certainly won't stop. ;) One would think
that it wouldn't be difficult to teach slocate about inotify. I briefly
looked into this and found rlocate but quickly realized that it requires
its own kernel module. Apparently this has been investigated[1] and
the inotify watch count limit becomes an issue very quickly. I seem to
recall, however, that there were some whispers on the LKML about adding
an interface that would be more capable of supporting such a system. I
can't seem to recall the details, however, and homework beckons.

Cheers,

- Ben

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[James Westby]

On Thu, 28 Jan 2010 18:12:52 +1300, martin f krafft  
wrote:
> also sprach Jameson Rollins  [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] tag dir proposal [was: Re: Git as notmuch object store]

[martin f krafft]

also sprach Jameson Rollins  [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.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: 

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[martin f krafft]

also sprach Jameson Rollins  [2010.01.26.1046 
+1300]:
> > For example, I might have:
> > 
> > ~/.notmuch-config:
> > 
> > [database]
> > path=/home/pioto/mail
> > ...
> > [tags]
> > pioto at 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.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: 

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[Ben Gamari]

Excerpts from martin f krafft's message of Thu Jan 28 15:39:10 -0500 2010:
> also sprach Servilio Afre Puentes  [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] tag dir proposal [was: Re: Git as notmuch object store]

[Servilio Afre Puentes]

2010/1/28 martin f krafft :
> also sprach Jameson Rollins  [2010.01.26.1046 
> +1300]:
>> > For example, I might have:
>> >
>> > ~/.notmuch-config:
>> >
>> > ? ? [database]
>> > ? ? path=/home/pioto/mail
>> > ? ? ...
>> > ? ? [tags]
>> > ? ? pioto at 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

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[Servilio Afre Puentes]

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]

[martin f krafft]

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]

[Ben Gamari]

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]

[Jed Brown]

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]

[martin f krafft]

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]

[martin f krafft]

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]

[James Westby]

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]

[martin f krafft]

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]

[James Westby]

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

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[Jameson Rollins]

On Tue, 26 Jan 2010 10:32:02 -0600, Scott Robinson  
wrote:
> 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?

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.

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

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[Scott Robinson]

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?

Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[Scott Robinson]

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

[notmuch] tag dir proposal [was: Re: Git as notmuch object store]

[Jameson Rollins]

On Mon, 25 Jan 2010 11:22:47 -0500 (EST), Mike Kelly  wrote:
>   Similarly, provide a mechanism for correlating the folder name with
>   some set of tags, and change those tags as messages are moved around.  
> 
> For example, I might have:
> 
> ~/.notmuch-config:
> 
> [database]
> path=/home/pioto/mail
> ...
> [tags]
> pioto at 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.

For instance, notmuch emacs (and emacs message-mode) is currently not
good at handling sent mail.  At the moment mail is just Bcc'd to
yourself.  However, this means that these sent messages end up back in
your inbox with 'inbox' and 'unread' tags which then need to be removed
so that the sent message is archived.  If one could configure notmuch
such that only new mail in an inbox directory would be tagged with
'inbox' and 'unread', and manage to coax emacs to fcc directly into an
archive, then these sent messages would not have the problematic 'inbox'
and 'unread' tags.  Even better, then sent mail could be fcc'd to a sent
mail directory would could then be configured to automatically get a
'sent' tag.

Notmuch emacs also currently does not handle message drafts, which makes
it very difficult to resume messages that were postponed from a previous
session.  If notmuch could be configured to tag messages in the
message-mode "message-auto-save-directory" with a 'draft' tag, then it
would greatly facilitate finding draft messages.

It would also be sweet if this could remove tags as well (maybe be
prepending '-' or '+' to the tag specification.  For example, I can
imagine implementing the above examples like this:

[database]
path=/home/jrollins/.mail

[tags]
inbox = +inbox,+unread
sent = +sent
drafts = +draft
archive = -inbox

I think we should definitely implement something like this.  It would
make things a lot more flexible.  Notmuch could be configured to not tag
any messages by default (which would make a lot of people using notmuch
for other backends happier) and then notmuch setup could could provide
an example tags stanza that would tag new messages with 'inbox' and
'unread' (maybe with a wildcard that would replicate the current
behavior):

[tags]
* = +inbox,+unread

I would love to see this.  Hopefully we can rally some more support for
this idea.

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