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