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 75DCE6DE0164 for ; Fri, 25 Aug 2017 18:50:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 tagged_above=-999 required=5 tests=[AWL=-0.013, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.211, 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 g1jbWY53v7f6 for ; Fri, 25 Aug 2017 18:50:14 -0700 (PDT) Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by arlo.cworth.org (Postfix) with ESMTPS id D990A6DE00DF for ; Fri, 25 Aug 2017 18:50:13 -0700 (PDT) Received: by mail-wr0-f170.google.com with SMTP id a47so3802626wra.4 for ; Fri, 25 Aug 2017 18:50:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MBhrDsLWDERkd7Edl6YdyPtxnt3q77InLAJ8DrclY0s=; b=GRlN2TZoIj7WgaCF7Xj2/nY8FzBraQeLHczBKHd2ybhTD58JOZJHqOxd02D4I8qIJO S8KY1vsKoBGjItPaWlX30uTlo0Lm8Kg28+twYzr6pn0PbDaNVghWysAuWILZ+WcSSEqC dV4AEcqynxqXSNEYZzdi12BsUZT8fiaXqEHBjdSfSmdGNFeBDpW/wD9dXDnbzjCP42Zt jkVxqDFdBBlA+HqYgRLfl/xyRwl05NTAD2Nr5r/MsIVh/vxIdJWhsbSlNQOzFMhV+Q06 bc2Sh58ZRlinYUhZqiKn0d2R0IRyBfoKxmdvwoQJ51IP4LIL9997A7fPscKF1sqvl+ap xzHg== X-Gm-Message-State: AHYfb5gnxbqaz99QiWg4jgRXHwXqbf4LHHRMO7urCd9czOPh6h8+N4x1 s65djvr3mhof+hXS64o= X-Received: by 10.223.139.92 with SMTP id v28mr183543wra.208.1503712210569; Fri, 25 Aug 2017 18:50:10 -0700 (PDT) Received: from home.thecybershadow.net (CyberShadow-1-pt.tunnel.tserv1.bud1.ipv6.he.net. [2001:470:1f1a:172::2]) by smtp.gmail.com with ESMTPSA id f4sm2451819wmh.28.2017.08.25.18.50.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Aug 2017 18:50:09 -0700 (PDT) Subject: Re: [PATCH 2/2] emacs: Add notmuch-update-search-tags To: David Bremner , notmuch@notmuchmail.org References: <20170814055457.7475-1-git@thecybershadow.net> <20170814055457.7475-3-git@thecybershadow.net> <87r2vz7vfh.fsf@tethera.net> From: Vladimir Panteleev Message-ID: <41a586b8-5059-7190-3ae6-ab6017795c28@gmail.com> Date: Sat, 26 Aug 2017 01:50:08 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <87r2vz7vfh.fsf@tethera.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Sat, 26 Aug 2017 01:50:15 -0000 On 2017-08-25 11:12, David Bremner wrote: > One side effect of this seems to be a regression, namely that in the > current buffer the "visual history" of tag changes is broken. Previously > deletions were shown by red strike-through and additions by green > underline. The deletions are now removed by the global update, and > additions shown on the wrong tags. Thanks for pointing that out. Fixed in v2. > Another aspect that is a bit surprising is that it doesn't change whether > threads actually match. For example if I have search for tag:inbox, > adding tag inbox to a thread won't cause the corresponding thread to > show up. This is maybe defensible, but it wasn't clear to me if it was > intentional. It is certainly intentional, though only reluctantly so. As far as I can tell, there is no way to update existing search buffers efficiently AND correctly, where "efficiently" means not simply performing the entire search query and repopulating the search buffer, and "correctly" means updating the buffer for deletions and additions so that the buffer contents would remain effectively the same before and after a notmuch-refresh-this-buffer invocation. notmuch-search is pretty slow; populating the "all mail" search result takes well over two minutes here (comparatively, for Thunderbird it takes no time at all). Refreshing all notmuch search buffers just because a tag changed somewhere (like point moving over an unread message in notmuch-show) is not a practical approach. Even though it would be possible to calculate the intersection between affected tags and a search buffer's query to find out which messages have been added or removed as an effect of the tagging operation, that still doesn't tell us where in the buffer the newly-added results would need to be inserted. Just plopping them at the end is an option, but not really a satisfying one. Same with duplicating the result ordering logic from the backend in the UI. Ideally, notmuch would offer a subscription mechanism, which would allow clients to subscribe to live changes in search queries, and receive updates as deltas from the original results. That's more of a daydream, though. In any case, I've updated the documentation of the variable to clarify that it does not cause results to be added or removed, but only update the display of the existing results. -- Best regards, Vladimir