From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 3A6B6431FB6 for ; Fri, 18 Mar 2011 00:32:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] 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 5M6UMjWBE6bx for ; Fri, 18 Mar 2011 00:32:03 -0700 (PDT) Received: from ipex1.johnshopkins.edu (ipex1.johnshopkins.edu [162.129.8.141]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 9DB16431FB5 for ; Fri, 18 Mar 2011 00:32:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,204,1299474000"; d="scan'208";a="54721673" Received: from c-69-255-36-229.hsd1.md.comcast.net (HELO lucky.home) ([69.255.36.229]) by ipex1.johnshopkins.edu with ESMTP/TLS/AES256-SHA; 18 Mar 2011 03:32:00 -0400 Received: from jkr by lucky.home with local (Exim 4.72) (envelope-from ) id 1Q0UAB-000338-L6; Fri, 18 Mar 2011 03:31:59 -0400 From: Jesse Rosenthal To: Ben Gamari , notmuch Subject: Re: My mail configuration In-Reply-To: <87tyfu3k5a.fsf@gmail.com> References: <87tyfu3k5a.fsf@gmail.com> User-Agent: Notmuch/0.5-81-g708c4f4 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu) Date: Fri, 18 Mar 2011 03:31:59 -0400 Message-ID: <877hbwevf4.fsf@lucky.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Fri, 18 Mar 2011 07:32:04 -0000 Hi Ben, On Wed, 23 Feb 2011 09:22:57 -0500, Ben Gamari wrote: > Here is my mail sorting script that has been slowly evolving for almost > a year now. Thanks for posting this, and sorry for digging this up so much later. I was thinking of setting up something similar, and had one question: > # Freeze new messages > q_new = notmuch.Query(db, 'tag:new') > n_msgs = 0 > for msg in q_new.search_messages(): > msg.freeze() > n_msgs += 1 It seems like every time you iterate over `q_new.search_messages()', you run a new search on tag:new. So at the end, when you thaw the messages, you're running that search again, from scratch: > # Tag remaining new items for inbox > tag_search(db, 'tag:new', '+inbox', '-new') > > # Thaw new messages > for msg in q_new.search_messages(): > msg.thaw() But there are no longer and "tag:new"s, so there shouldn't be any results for `q_new.search_messages()', should there? It seems like it's thawing 0 messages. Playing around with it, it doesn't seem to make a difference, so perhaps thawing is unneccessary if you're exiting after tagging. Or am I misunderstanding something? By the way, my understanding of the bindings is that you can avoid running the new searches by dumping a Messages object into a list. So, you can do something like: new_msg_obj = q_new.search_messages() new_msg_list = [m for m in new_msg_obj] and then deal with the list from there on out. Not sure if that would buy you much performance over running the query repeatedly, but it couldn't hurt, and it would seem closer to the effect that you're aiming at (since the members of the list would be set from the first query, and therefore you'd be thawing the same elements you froze in the first place). Thanks again for posting this. Best, Jesse