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 493C4414448 for ; Sun, 8 Jan 2012 17:13:02 -0800 (PST) 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 MDpvEJOprdSr for ; Sun, 8 Jan 2012 17:12:57 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by olra.theworths.org (Postfix) with ESMTP id 7939641444B for ; Sun, 8 Jan 2012 17:12:49 -0800 (PST) X-AuditID: 12074425-b7f4a6d0000008e0-a9-4f0a3f109c84 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 21.26.02272.01F3A0F4; Sun, 8 Jan 2012 20:12:48 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q091Clse002712; Sun, 8 Jan 2012 20:12:47 -0500 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q091CjUv003302 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 8 Jan 2012 20:12:46 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1Rk3nH-0005uz-Oo; Sun, 08 Jan 2012 20:12:59 -0500 Date: Sun, 8 Jan 2012 20:12:59 -0500 From: Austin Clements To: Aaron Ecay Subject: Re: [PATCH] emacs: call "notmuch tag" only once when archiving a thread Message-ID: <20120109011259.GD20796@mit.edu> References: <1325615346-8302-1-git-send-email-jani@nikula.org> <87fwftao1b.fsf@nikula.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUixG6noitgz+Vv8Oksh8W05V/YLZqmO1tc vzmT2YHZY+esu+wet+6/Zvd4tuoWcwBzFJdNSmpOZllqkb5dAlfGh72fWAp+cVf0fvvN2MB4 nrOLkZNDQsBE4uC+LWwQtpjEhXvrgWwuDiGBfYwSPx+8Z4Zw1jNKXJnSzwThnGCSaL09Hyqz hFHi4sXNjCD9LAIqEms+9bCA2GwCGhLb9i8Hi4sAxWfPmw9mMwtYSTRs+QBmCwsESXya/Q5s N6+AjsSnj6+hNkxjlJg08TMLREJQ4uTMJywQzeoSf+ZdAtrMAWRLSyz/xwERlpdo3jqbGcTm BCp51/ILzBYF2jvl5Da2CYzCs5BMmoVk0iyESbOQTFrAyLKKUTYlt0o3NzEzpzg1Wbc4OTEv L7VI10IvN7NELzWldBMjODpcVHcwTjikdIhRgINRiYdXwIbLX4g1say4MvcQoyQHk5Iob5gt UIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr4AZUI43JbGyKrUoHyYlzcGiJM6rqfXOT0ggPbEk NTs1tSC1CCYrw8GhJMHraQfUKFiUmp5akZaZU4KQZuLgBBnOAzQ8AqSGt7ggMbc4Mx0if4pR l+N649xzjEIsefl5qVLivPEgRQIgRRmleXBzYEntFaM40FvCvG4gVTzAhAg36RXQEiagJQ/+ sIMsKUlESEk1MJZGLvN6pS58JOCyYKhi892CUJbFN5dwbOivyF0s3rVko/Lq7/9uWbYo9pyo nLc9InG7S573g2zlnR98g7drf/IWfdj0ye7cvh3Mv3PNy49uv13LmrA9rySKs/b576TMdxJH ckumcXMxv/vFUfnXVNmEZ7fX9uKN725L+Bop7aruvPb68HbVj0osxRmJhlrMRcWJALJx5wxF AwAA 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: Mon, 09 Jan 2012 01:13:07 -0000 Quoth Aaron Ecay on Jan 08 at 7:56 pm: > On Thu, 05 Jan 2012 22:32:16 +0200, Jani Nikula wrote: > > [...] > > > In the show view it only modifies the messages that are currently > > visible. This is to make sure you don't accidentally archive things that > > have arrived after refreshing the buffer. I think this is safest. > > Hmm. Perhaps it would make sense to add a check in the search view that > the thread being archived[1] has the same number of messages as it did > when the buffer was constructed. (The information on how many messages > the thread has is in the buffer; we would then compare this to the result > of “notmuch count thread:000foo” when the user requests to archive.) If > the counts don’t match, the interface should show a message in the echo > area and (probably) refuse to do the tagging. That sounds like a clever workaround. There's been quite a bit of discussion on fixing this properly. See, for example id:"CAH-f9WsPj=1Eu=g3sOePJgCTBFs6HrLdLq18xMEnJ8aZ00yCEg@mail.gmail.com". The gist is that we need to include message IDs (or document IDs) in the search output and use these in tagging operations, rather than the unstable thread:XXX queries. Unfortunately, actually fixing this got stalled since adding this information the text format is a fool's errand (having been the fool, I can say this!), so we need to switch Emacs over to using the JSON search format first. However, once that's done, it's a relatively simple change.