From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id BEA2B6DE0352 for ; Sun, 27 Aug 2017 00:47:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.079 X-Spam-Level: X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[AWL=-0.051, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o78P7zXtSlsB for ; Sun, 27 Aug 2017 00:46:59 -0700 (PDT) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by arlo.cworth.org (Postfix) with ESMTPS id 48A4B6DE0350 for ; Sun, 27 Aug 2017 00:46:59 -0700 (PDT) Received: by mail-wm0-f51.google.com with SMTP id w3so9461651wmf.0 for ; Sun, 27 Aug 2017 00:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=WPS2K6eY6KkcgTc9ZJHphcEAgvtfDMAeGFviym9ZlVI=; b=NISuNwBgOmR+Aotdk3SHEqJiPxB1xppddWh2r8uKvcPG7JBEpvAizQVekt+foX5EO5 IYOU9k9hE2ipA/hiTVA9iKxnreO/mgH8AwY42iKGVLbycZuFViOS4Srk+1o+3yLvT1Z4 ftZ9o4KD6Db/ebyibXT0tuvD8NwQNgqtjCwcUXKku6PIs6zePz6xyptb/R/qZRm0iu0A V4Tc4jbgfbJTT7DwvKJvHshNbM5oalX6GWWiuoWVIyj4phdtLSR49MwDaninPuviej7L BCBkI2yY6A06v42mm/zSdBhYCYVjAZYonivTbOoUmDOaQ+a+4/nqB6aJmEFM0B58LfMJ jJ9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=WPS2K6eY6KkcgTc9ZJHphcEAgvtfDMAeGFviym9ZlVI=; b=VXDpQebGb7Le0vp65ifzJnhUuglaxJ6+0TY1olTTHFiCBWZJWii2fu+4VRxDZ0bYPm 6c/EjQ6U/ZCn3K4GsU2gv+JKFFVz4ClN6IvzoMLo1385XfhO/h0eugBzeAwqg03bases EMqllfNggSZbh8cmJD+plT27ckh1EH+sN33ocuRZbICUiAlsbfpynbCxgSRJjfTEAWE3 Tst+D3nCvfkhLtEtfKuJolB2Vsd7DR9Wx5uYo3Kj1q7bRDHnjwr0sQw5zOiYn4HN9Ra3 qnl7GbFy99UV+EQy22zSCyV7elDMp0QTKg0jwyfe1v4j564duUx+NGFZ1E5mgz9pltxW 3vFw== X-Gm-Message-State: AHYfb5ijcfdnpq+khDoGCCXmRK8AMdrDhJGn/M7EPKnP3b4U4l1afLDy QjGD8V0ZxUEnrg== X-Received: by 10.28.156.205 with SMTP id f196mr1605712wme.32.1503820015295; Sun, 27 Aug 2017 00:46:55 -0700 (PDT) Received: from localhost (5751dfa2.skybroadband.com. [87.81.223.162]) by smtp.gmail.com with ESMTPSA id h66sm5772312wmd.38.2017.08.27.00.46.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Aug 2017 00:46:54 -0700 (PDT) From: Mark Walters To: Vladimir Panteleev , notmuch@notmuchmail.org Cc: Vladimir Panteleev Subject: Re: [PATCH v2] emacs: Add notmuch-update-search-tags In-Reply-To: References: <41a586b8-5059-7190-3ae6-ab6017795c28@gmail.com> <20170826015541.25937-1-notmuch@thecybershadow.net> <87a82mzkyg.fsf@qmul.ac.uk> Date: Sun, 27 Aug 2017 08:46:53 +0100 Message-ID: <8760d9qwpe.fsf@qmul.ac.uk> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 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: Sun, 27 Aug 2017 07:47:00 -0000 Hi OK I have now actually tested it, and I have read the patch more carefully, but I am afraid I still have concerns. The key problem is the patch assumes that the display of a thread in a search buffer depends only on the thread. And this is not true as the number of matching messages is displayed eg [10/19], and the author list is split into matching authors | unmatching authors. However, when the tags in a thread are changed the patch makes all search buffers containing that thread update to look the same. Indeed, if you change a tag on a single message I think the count will always update to be [1/??] as there is only one message matching the tag-change query. I think you could get round this by modifying your code only slightly -- rather than calling notmuch-search-update-result in notmuch-search-update-results, *just* update the tags, using something like notmuch-search-set-tags. (I have just tried this and it seems to work.) This is not perfect, as this will show tags of newly arrived messages in the thread, but that might well be acceptable. And this still keeps it to one call to the database, which avoids your (completely correct) performance concerns. > It may be possible to optimize this down to one batch search query per > notmuch-search buffer - however, this results in a large search query. > Not only would one take a while to execute, but the resulting query can > become too large to be passed as a command-line parameter, and "notmuch > search" does not seem to have a --batch switch to read queries from > standard input. This points to my next concern -- this is already a problem in the current patch. If you go into a moderately large search buffer, and do something like * +foo (to tag all the messages with foo), the tag step works because is uses the --batch switch to tag, but your search query doesn't. The options here are to: add --batch to search handling, or just decide not to do display the tag updates for large queries. Incidentally there also seems to a bug in the current that the first thread in a search buffer doesn't seem to get updated. I think you are using too low level functions -- things like notmuch-search-foreach-result might do exactly what you need. Finally, in the longer term, do you wanting to do this for tree and show buffers too? [An alternative approach, which I don't think I like but I mention in case others do -- we could only propagate tag changes to parent buffers. So updating a tag in a show buffer only updates the single search buffer that called it. This might avoid the large query problem as show buffers probably don't have large queries.] Best wishes Mark