Message-ID: <4BC31133.6000105@dbservice.com>
Date: Mon, 12 Apr 2010 14:25:23 +0200
From: Tomas Carnecky <tom@dbservice.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
	rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Jameson Rollins <jrollins@finestructure.net>
Subject: Re: [PATCH] notmuch new --new-tags=tags...
References: <n2x87b3a4191004100803z9d4c4c2bp52f5cf0d7b712362@mail.gmail.com>
	<871velp0be.fsf@SSpaeth.de>	<87y6gseval.fsf@servo.finestructure.net>
In-Reply-To: <87y6gseval.fsf@servo.finestructure.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: notmuch <notmuch@notmuchmail.org>, Anthony Towns <aj@erisian.com.au>
Precedence: list

On 4/12/10 1:59 PM, Jameson Rollins wrote:
> On Mon, 12 Apr 2010 10:00:37 +0200, "Sebastian Spaeth"<Sebastian@SSpaeth.de>  wrote:
>> On 2010-04-10, Anthony Towns wrote:
>>> The attached patch makes "notmuch new --new-tags=unread,new" set the
>>> "unread" and "new" tags on any new mail it finds rather than "unread"
>>> and "inbox". Or whatever other tags you happen to specify.
>>
>> Thanks for the patch. I can't comment on the code quality, but rather
>> than having to specify the set of new tags on the command line every
>> time, I think it would make more sense to put them in the notmuch config
>> file as this patch does:
>> id:1268432006-24333-2-git-send-email-bgamari.foss@gmail.com
>
> I was thinking about this, and it seems to me that we really need is a
> way to just specify which tags should be applied to new messages based
> on search terms.  It's becoming pretty clear that most people are doing
> some sort of post-notmuch-new tag processing to modify the tags of new
> messages to suite their needs.  Why not just integrate this directly
> into the notmuch-new processing itself?  It seems like if this was
> integrated into notmuch-new directly, the entire processing of new
> messages could be sped up considerably, so that one wouldn't have to
> call multiple notmuch-new processes in succession.
>
> I'm not sure exactly what the best way to handle it would be, but I can
> imagine something like this:
>
> [new-tags]
> +sent -new -- from:jrollins@finestructure.net
> +drafts -new -- folder:draft
> +notmuch -- from:notmuch@notmuchmail.org
> +unread +inbox -new -- tag:new
>
> These are all just commands for "notmuch tag" that would be run on all
> the new messages as they're processed.  Each new message would be given
> "new" tag by default, and then the new tag commands would be run.  So it
> would be the equivalent of running the following commands:
>
> notmuch new --new-tags=new
> notmuch tag +sent -new -- from:jrollins@finestructure.net
> notmuch tag +drafts -new -- folder:draft
> notmuch tag +notmuch -- from:notmuch@notmuchmail.org
> notmuch tag +unread +inbox -- tag:new
>
> This would make things much easier for everyone who is doing post-new
> tag processing, which I think is probably most people.  And I'm sure it
> could be made much more efficient (if coded properly) than running all
> these notmuch commands in succession, especially for people who have a
> lot of post-new tag processing to do.  Keeping the syntax identical to
> the notmuch-tag command syntax would keep things simple as well.
>
> Do people who do a lot of post-notmuch-new tag processing think
> something like this would suite their needs?

I have a patch which adds support for hooks which are run when tags are 
added, removed or new messages added to notmuch. But perhaps the 
fork/exec overhead of running the hooks would slow the processing down 
too much.
See http://caurea.org/2009/12/22/a-different-approach-to-email-tagging/, 
though that didn't work out quite how I expected. Classifying spam/ham 
is easy (that's what dspam was written for), but patch/not-patch 
resulted in a lot false-positives, especially when people quote emails 
which included patches. Same with the 'notmuch' and 'xorg' tags: dspam 
had trouble figuring out to which mailing list Carl sent the email (he 
sends emails to both lists).

tom