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