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 EB016431FAF for ; Wed, 9 Oct 2013 09:19:21 -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 z2jxCG5PN5oI for ; Wed, 9 Oct 2013 09:19:13 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by olra.theworths.org (Postfix) with ESMTP id 5F953431FAE for ; Wed, 9 Oct 2013 09:19:13 -0700 (PDT) X-AuditID: 1209190f-b7fa08e0000009c6-43-525582003fd0 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 19.79.02502.00285525; Wed, 9 Oct 2013 12:19:12 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r99GJBkq021983; Wed, 9 Oct 2013 12:19:12 -0400 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.8/8.12.4) with ESMTP id r99GJ9N8013385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 9 Oct 2013 12:19:11 -0400 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80) (envelope-from ) id 1VTwTd-0005fI-5h; Wed, 09 Oct 2013 12:19:09 -0400 Date: Wed, 9 Oct 2013 12:19:08 -0400 From: Austin Clements To: Mark Walters Subject: Re: [PATCH 00/11] Fix search tagging races Message-ID: <20131009161907.GS21611@mit.edu> References: <1381185201-25197-1-git-send-email-amdragon@mit.edu> <87ob70kxg1.fsf@qmul.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ob70kxg1.fsf@qmul.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT12VoCg0y6G2xtFg9l8fi+s2ZzA5M Hjtn3WX3eLbqFnMAUxSXTUpqTmZZapG+XQJXxok315kLpklUTH3TwtjAuFG4i5GTQ0LARGJO 9yRWCFtM4sK99WxdjFwcQgL7GCXWHzjGCuFsYJRoWLSYEcI5xSRx4s0VdpAWIYEljBLt3UJd jBwcLAIqElfXFoCE2QQ0JLbtX84IYosI6EjcPrQArJxZQFri2+9mJhBbWMBYYv3OE8wgNi9Q zbnmf4wQI+Mkjkw7ChUXlDg58wkLRK+WxI1/L5lAVoHMWf6PAyTMCbTq45urYCWiQBdMObmN bQKj0Cwk3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10QvN7NELzWldBMjKKQ5 Jfl3MH47qHSIUYCDUYmHt6IsNEiINbGsuDL3EKMkB5OSKK9pA1CILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCG9cCVCONyWxsiq1KB8mJc3BoiTOe5PDPkhIID2xJDU7NbUgtQgmK8PBoSTBuw9k qGBRanpqRVpmTglCmomDE2Q4D9DwmyA1vMUFibnFmekQ+VOMilLivMaNQAkBkERGaR5cLyzl vGIUB3pFmFcUpIoHmK7gul8BDWYCGrz9ewjI4JJEhJRUA6PDkp6ybVLCtyQCfc3D1n48OyXU 8V9v3p45i9U593TuDu1aqMK7/9OCFN+sMx+OvkyafOuG0OGzF6bUJjzeF/FzpjenRf3UCxPL 9s9x4j2lcunElboVRh+Y97FlHvsfdMaiXCn7TlZa6L8qx9c9kjemH/i+8J3f8w+sjAwVHe8q bp0sUi6oMa9RYinOSDTUYi4qTgQA+BV1qxQDAAA= 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: Wed, 09 Oct 2013 16:19:22 -0000 Quoth Mark Walters on Oct 08 at 8:56 am: > > Hello > > It's great that this might finally get done. But there is one problem > currently. > > If you open a large search buffer and then do *- it will die as the > tagging routine runs notmuch search to find a completion-list for the > tag. (it runs notmuch search --output=tags ) Hmm. If we implement docid queries (described in the TODO added by this series), we should be able to get away with what we're doing now without any serious performance problems... > We could just return all tags in this case. Or we could do something > like the series > id:1354263691-19715-1-git-send-email-markwalters1009@gmail.com > which makes completion happen based on the tags visible to the user, not > the tags actually in the database. OTOH, I think what you were going for in this series is the right thing to do from a UI perspective anyway. I'll try implementing something along these lines, though I've got an idea that I think will by more Elispy. Currently `notmuch-tag' has this strange interface where it can interactively prompt in some cases. This isn't the right way to do this. `notmuch-tag' should be non-interactive and the interactive tagging commands should have an interactive specification that prompts for tags to change, right at the interactive entry point. This should give us a clean place to provide a list of existing tags, and would also let us do other nice things like specify a different tag prompt for * commands, and maybe add a y/n prompt to confirm a * tagging command. It would also provide a convenient place to wait for search results to finish coming in after prompting in the * command, which would be awkward to do right now. > There is also a little discussion of this in my earlier attempt at > fixing this: eg id:87mwy4smad.fsf@qmul.ac.uk > > Best wishes > > Mark > > On Mon, 07 Oct 2013, Austin Clements wrote: > > I was hacking on undo support for notmuch-emacs and sort of > > accidentally wrote this instead. This series fixes a set of > > well-known races where tagging from search-mode unexpectedly affects > > messages that arrived after the search was performed (and hence the > > user doesn't know they're tagging them). We've attacked this a few > > times before, but have always run up against something that was > > missing. It turns out the pieces are finally all in place. > > > > The first five patches just clean various things up in preparation. > > Patches 6 and 7 add support for tagging large queries, which would > > otherwise become a problem when later patches start using explicit > > message ID-based queries for tagging. The remaining four patches > > actually fix the search tagging races using explicit message ID-based > > queries. > > > > It's a fairly long series, but none of the patches are very big. > > > > _______________________________________________ > > notmuch mailing list > > notmuch@notmuchmail.org > > http://notmuchmail.org/mailman/listinfo/notmuch