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 02B16429E25 for ; Sat, 2 Jul 2011 07:20:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 xIr6vvzGkZeU for ; Sat, 2 Jul 2011 07:20:44 -0700 (PDT) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id A0B41431FD0 for ; Sat, 2 Jul 2011 07:20:44 -0700 (PDT) Received: by wyh22 with SMTP id 22so3070359wyh.26 for ; Sat, 02 Jul 2011 07:20:43 -0700 (PDT) Received: by 10.227.156.70 with SMTP id v6mr3876933wbw.21.1309616443125; Sat, 02 Jul 2011 07:20:43 -0700 (PDT) Received: from localhost (91.216-242-81.adsl-dyn.isp.belgacom.be [81.242.216.91]) by mx.google.com with ESMTPS id fp5sm1811256wbb.66.2011.07.02.07.20.40 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Jul 2011 07:20:41 -0700 (PDT) From: Pieter Praet To: Austin Clements Subject: Re: [PATCH 2/2] [RFC] possible solution for "Race condition for '*' command" In-Reply-To: References: User-Agent: Notmuch/0.5-315-g34bd5eb (http://notmuchmail.org) Emacs/23.1.50.1 (x86_64-pc-linux-gnu) Date: Sat, 02 Jul 2011 16:20:39 +0200 Message-ID: <87zkkwydag.fsf@praet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: notmuch@notmuchmail.org 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: Sat, 02 Jul 2011 14:20:46 -0000 On Fri, 1 Jul 2011 12:37:11 -0400, Austin Clements wrote: Non-text part: multipart/alternative > On Jul 1, 2011 10:55 AM, "Austin Clements" wrote: > > > > On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet wrote: > > > Ok, even though my very first reply [1] may have created the impression > > > that I understood the issue, I clearly didn't... > > > > > > The test [2] needs a more applicable commit message, and the subsequent > > > patch [3] points more or less in the right direction, but the Message-Id > > > list should be local to the *search buffer* rather than to the > > > `notmuch-search-operate-all' function. > > > > > > `notmuch-search' could: > > > - run "notmuch-command search" with the "--output=messages" option > > > instead of a plain search, > > > - maintain a buffer-local var with a list of returned Message-Id's, > > > - ...and populate the buffer based on that list. > > > > > > As such we'd have -for each individual search buffer- a canonical list > > > of Message-Id's (i.e. messages which actually *match* the query AND are > > > currently visible in the search buffer), to be used by > > > `notmuch-search-operate-all' et al. > > > > > > > > > Peace > > > > > > -- > > > Pieter > > > > > > [1] id:"87fwmuxxgd.fsf@praet.org" > > > [2] id:"1309450108-2793-2-git-send-email-pieter@praet.org" > > > [3] id:"1309450108-2793-1-git-send-email-pieter@praet.org" > > > > Ideally, this wouldn't be per-buffer, but per *line*. This race > > equally affects adding and removing tags from individual results, > > since that's done using a thread: query, whose results could have > > changed since the original search. > > > > This almost certainly requires support from the notmuch core. The > > good news is that the library already provides this information, so > > there will be virtually no performance hit for outputting it. > > Actually, with a smidgeon of library support, you could even use document > IDs for this, rather than message IDs, which would make the tagging > operations (even '*') no more expensive than they are now. (Of course, it > would be good to know just how much overhead going through message IDs > actually introduces.) Non-text part: text/html That would be awesome! Though I'd rather leave the plumbing to someone sufficiently capable, so, if leaving libnotmuch hacking out of the equation, how would one go about doing this? I (ignorantly) assume we'd get `notmuch-search-process-filter' to append each line with an invisible field containing a list of matching Message-Id's, presumably obtained via `notmuch_thread_get_matched_messages' (@ lib/thread.cc) ? Peace -- Pieter