--- /dev/null
+Return-Path: <Vladimir.Marek@Oracle.COM>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 0A5C5431FAF\r
+ for <notmuch@notmuchmail.org>; Mon, 12 Aug 2013 02:35:48 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.299\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001]\r
+ autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id 6ddq3J8+NOkY for <notmuch@notmuchmail.org>;\r
+ Mon, 12 Aug 2013 02:35:41 -0700 (PDT)\r
+Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id D7D1F431FAE\r
+ for <notmuch@notmuchmail.org>; Mon, 12 Aug 2013 02:35:41 -0700 (PDT)\r
+Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])\r
+ by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with\r
+ ESMTP id r7C9Zduq003668\r
+ (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)\r
+ for <notmuch@notmuchmail.org>; Mon, 12 Aug 2013 09:35:40 GMT\r
+Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230])\r
+ by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id\r
+ r7C9ZcYY025994\r
+ (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)\r
+ for <notmuch@notmuchmail.org>; Mon, 12 Aug 2013 09:35:39 GMT\r
+Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])\r
+ by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id\r
+ r7C9ZcWP025987\r
+ for <notmuch@notmuchmail.org>; Mon, 12 Aug 2013 09:35:38 GMT\r
+Received: from virt.cz.oracle.com (/10.163.102.127)\r
+ by default (Oracle Beehive Gateway v4.0)\r
+ with ESMTP ; Mon, 12 Aug 2013 02:35:37 -0700\r
+Date: Mon, 12 Aug 2013 11:34:43 +0200\r
+From: Vladimir Marek <Vladimir.Marek@Oracle.COM>\r
+To: notmuch@notmuchmail.org\r
+Subject: Possible addtions to notmuch new ?\r
+Message-ID: <20130812093443.GB16684@virt.cz.oracle.com>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Disposition: inline\r
+User-Agent: Mutt/ (2012-12-30)\r
+X-Source-IP: acsinet21.oracle.com [141.146.126.237]\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 12 Aug 2013 09:35:48 -0000\r
+\r
+Hi,\r
+\r
+My mail setup is a directory containing several subdirectories each\r
+subdirectory corresponds to one real mail account I am using. Each mail\r
+account is synchronized differently - I am using offlineimap, fetchmeail\r
+or even synthetically created emails (I am writing very simple jabber<->\r
+mail gate).Every now and then I am running 'notmuch new' to discover new\r
+emails and make them available in my MUA.\r
+\r
+That works pretty well, but has some disadvantages too\r
+ - notmuch new takes very long time (30s) during which the notmuch\r
+ database seems to be locked for any other updates from my MUA\r
+ - notmuch new takes long time because it always processes my archive\r
+ dir containing many files. That's mostly un-necessary as typically\r
+ there's no new mail delivered\r
+ - I don't have the possibility of passing new mails through procmail.\r
+ That would be useful for example for changing cron mail subjects,\r
+ putting related automated mails into threads (bugzilla, etc.).\r
+\r
+\r
+I was thinking that if we could split the new mail discovery from\r
+it's processing, it would solve the disadvantages I'm facing. Something\r
+like\r
+\r
+notmuch new --verbose --dry-run [dir] | my_filter | notmuch insert -\r
+\r
+It would work\r
+ - --dry-run would not lock and change the database\r
+ - --verbose would print the changes to stdout/stderr. Something like:\r
+\r
+new mail/file.1\r
+new mail/file.2\r
+deleted mail/file.3\r
+renamed mail/file.4 mail/file.5\r
+...\r
+\r
+[dir] would limit the scope of 'notmuch' new search to dir and it's\r
+subdirectories. Alternatively we could have set of include or exclude\r
+rules similarly to rsync (for example), but [dir] is easier to\r
+implement.\r
+\r
+'my_filter' would be my script which could change the contents of emails\r
+before they are inserted into notmuch database.\r
+\r
+Notmuch insert would be able to not only add new mails, but also remove\r
+old ones or note that the file was renamed.\r
+\r
+How would this sound?\r
+\r
+I'm not saying I would implement this, I'm rather curious where would\r
+you like to see notmuch in the future.\r
+\r
+Cheers\r
+-- \r
+ Vlad\r