88/33b3653d8f7c7b122a82daad65e4d00caf99aa

   1 Return-Path: <tom@dbservice.com>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 946F34196F2\r
   6         for <notmuch@notmuchmail.org>; Mon, 12 Apr 2010 05:25:37 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.001\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5\r
  12         tests=[BAYES_20=-0.001] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id KSW6Muj2crCP for <notmuch@notmuchmail.org>;\r
  16         Mon, 12 Apr 2010 05:25:36 -0700 (PDT)\r
  17 Received: from office.neopsis.com (office.neopsis.com [78.46.209.98])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 384BC431FC1\r
  19         for <notmuch@notmuchmail.org>; Mon, 12 Apr 2010 05:25:36 -0700 (PDT)\r
  20 Received: from calvin.caurea.org ([62.65.141.13])\r
  21         (authenticated user tom@dbservice.com) by office.neopsis.com\r
  22         (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits));\r
  23         Mon, 12 Apr 2010 14:25:23 +0200\r
  24 Message-ID: <4BC31133.6000105@dbservice.com>\r
  25 Date: Mon, 12 Apr 2010 14:25:23 +0200\r
  26 From: Tomas Carnecky <tom@dbservice.com>\r
  27 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;\r
  28         rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4\r
  29 MIME-Version: 1.0\r
  30 To: Jameson Rollins <jrollins@finestructure.net>\r
  31 Subject: Re: [PATCH] notmuch new --new-tags=tags...\r
  32 References: <n2x87b3a4191004100803z9d4c4c2bp52f5cf0d7b712362@mail.gmail.com>\r
  33         <871velp0be.fsf@SSpaeth.de>     <87y6gseval.fsf@servo.finestructure.net>\r
  34 In-Reply-To: <87y6gseval.fsf@servo.finestructure.net>\r
  35 Content-Type: text/plain; charset=UTF-8; format=flowed\r
  36 Content-Transfer-Encoding: 7bit\r
  37 Cc: notmuch <notmuch@notmuchmail.org>, Anthony Towns <aj@erisian.com.au>\r
  38 X-BeenThere: notmuch@notmuchmail.org\r
  39 X-Mailman-Version: 2.1.13\r
  40 Precedence: list\r
  41 List-Id: "Use and development of the notmuch mail system."\r
  42         <notmuch.notmuchmail.org>\r
  43 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  44         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  45 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  46 List-Post: <mailto:notmuch@notmuchmail.org>\r
  47 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  48 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  49         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  50 X-List-Received-Date: Mon, 12 Apr 2010 12:25:37 -0000\r
  51 \r
  52 On 4/12/10 1:59 PM, Jameson Rollins wrote:\r
  53 > On Mon, 12 Apr 2010 10:00:37 +0200, "Sebastian Spaeth"<Sebastian@SSpaeth.de>  wrote:\r
  54 >> On 2010-04-10, Anthony Towns wrote:\r
  55 >>> The attached patch makes "notmuch new --new-tags=unread,new" set the\r
  56 >>> "unread" and "new" tags on any new mail it finds rather than "unread"\r
  57 >>> and "inbox". Or whatever other tags you happen to specify.\r
  58 >>\r
  59 >> Thanks for the patch. I can't comment on the code quality, but rather\r
  60 >> than having to specify the set of new tags on the command line every\r
  61 >> time, I think it would make more sense to put them in the notmuch config\r
  62 >> file as this patch does:\r
  63 >> id:1268432006-24333-2-git-send-email-bgamari.foss@gmail.com\r
  64 >\r
  65 > I was thinking about this, and it seems to me that we really need is a\r
  66 > way to just specify which tags should be applied to new messages based\r
  67 > on search terms.  It's becoming pretty clear that most people are doing\r
  68 > some sort of post-notmuch-new tag processing to modify the tags of new\r
  69 > messages to suite their needs.  Why not just integrate this directly\r
  70 > into the notmuch-new processing itself?  It seems like if this was\r
  71 > integrated into notmuch-new directly, the entire processing of new\r
  72 > messages could be sped up considerably, so that one wouldn't have to\r
  73 > call multiple notmuch-new processes in succession.\r
  74 >\r
  75 > I'm not sure exactly what the best way to handle it would be, but I can\r
  76 > imagine something like this:\r
  77 >\r
  78 > [new-tags]\r
  79 > +sent -new -- from:jrollins@finestructure.net\r
  80 > +drafts -new -- folder:draft\r
  81 > +notmuch -- from:notmuch@notmuchmail.org\r
  82 > +unread +inbox -new -- tag:new\r
  83 >\r
  84 > These are all just commands for "notmuch tag" that would be run on all\r
  85 > the new messages as they're processed.  Each new message would be given\r
  86 > "new" tag by default, and then the new tag commands would be run.  So it\r
  87 > would be the equivalent of running the following commands:\r
  88 >\r
  89 > notmuch new --new-tags=new\r
  90 > notmuch tag +sent -new -- from:jrollins@finestructure.net\r
  91 > notmuch tag +drafts -new -- folder:draft\r
  92 > notmuch tag +notmuch -- from:notmuch@notmuchmail.org\r
  93 > notmuch tag +unread +inbox -- tag:new\r
  94 >\r
  95 > This would make things much easier for everyone who is doing post-new\r
  96 > tag processing, which I think is probably most people.  And I'm sure it\r
  97 > could be made much more efficient (if coded properly) than running all\r
  98 > these notmuch commands in succession, especially for people who have a\r
  99 > lot of post-new tag processing to do.  Keeping the syntax identical to\r
 100 > the notmuch-tag command syntax would keep things simple as well.\r
 101 >\r
 102 > Do people who do a lot of post-notmuch-new tag processing think\r
 103 > something like this would suite their needs?\r
 104 \r
 105 I have a patch which adds support for hooks which are run when tags are \r
 106 added, removed or new messages added to notmuch. But perhaps the \r
 107 fork/exec overhead of running the hooks would slow the processing down \r
 108 too much.\r
 109 See http://caurea.org/2009/12/22/a-different-approach-to-email-tagging/, \r
 110 though that didn't work out quite how I expected. Classifying spam/ham \r
 111 is easy (that's what dspam was written for), but patch/not-patch \r
 112 resulted in a lot false-positives, especially when people quote emails \r
 113 which included patches. Same with the 'notmuch' and 'xorg' tags: dspam \r
 114 had trouble figuring out to which mailing list Carl sent the email (he \r
 115 sends emails to both lists).\r
 116 \r
 117 tom\r
 118 \r
 119 \r