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 A7153431FAF for ; Fri, 20 Jan 2012 09:18:23 -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 c+pLJgP7PG66 for ; Fri, 20 Jan 2012 09:18:23 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by olra.theworths.org (Postfix) with ESMTP id 0724C431FAE for ; Fri, 20 Jan 2012 09:18:22 -0800 (PST) X-AuditID: 1209190e-b7f7c6d0000008c3-b9-4f19a1de49c6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B2.18.02243.ED1A91F4; Fri, 20 Jan 2012 12:18:22 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id q0KHIMB2026348; Fri, 20 Jan 2012 12:18:22 -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 q0KHILSm012234 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 20 Jan 2012 12:18:22 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1RoI6D-0006H2-Bm; Fri, 20 Jan 2012 12:18:01 -0500 Date: Fri, 20 Jan 2012 12:18:01 -0500 From: Austin Clements To: Mark Walters Subject: Re: [PATCH] Automatically exclude tags in notmuch-show Message-ID: <20120120171801.GA16740@mit.edu> References: <874nvric7c.fsf@qmul.ac.uk> <1327010583-23954-1-git-send-email-markwalters1009@gmail.com> <20120119225910.GT16740@mit.edu> <871uqvgrnm.fsf@qmul.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871uqvgrnm.fsf@qmul.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT1723UNLf4ModdYvVc3ksrt+cyezA 5LFz1l12j2erbjEHMEVx2aSk5mSWpRbp2yVwZUz6MoWtoF2oYubq6awNjPP5uhg5OSQETCSW bVjIBGGLSVy4t56ti5GLQ0hgH6PEwf6HTBDOBkaJ1i2rmSGck0wSLxd2sUA4Sxgl5l5axA7S zyKgKnF18UdGEJtNQENi2/7lYLaIgI7E7UMLwGqYBaQlvv1uBtsnLGAvMXnpYmYQmxeo5vCs l+wQQ1cwSrR3b2WFSAhKnJz5hAWiWUvixr+XQM0cYIOW/+MACXMC7brzYxpYiaiAisSUk9vY JjAKzULSPQtJ9yyE7gWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfVyM0v0UlNKNzGCAptT km8H49eDSocYBTgYlXh4OV0l/IVYE8uKK3MPMUpyMCmJ8krOk/QX4kvKT6nMSCzOiC8qzUkt PsQowcGsJMJb1gWU401JrKxKLcqHSUlzsCiJ86ppvfMTEkhPLEnNTk0tSC2CycpwcChJ8NYC I1hIsCg1PbUiLTOnBCHNxMEJMpwHaHgDSA1vcUFibnFmOkT+FKOilDivE0hCACSRUZoH1wtL PK8YxYFeEeaNAaniASYtuO5XQIOZgAZ7NImBDC5JREhJNTBmxWb2x29cFnK66b7Ghk/ep16o 8J3P3RKduVTVofGZV3VdCctbHzsRpYNiP7bPXrBmvUBiQs4kKfEXj+e1Trq6X9+Q+bvMK8dL Mfx6Xtc3TMqOs36/Rmiae7hwlfuFqNRZ5zXN4kTWyL17uDxFZMctY86vNyU54kvfCb2a9Idz nwebL8eVrOlKLMUZiYZazEXFiQDXLSNRFwMAAA== 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: Fri, 20 Jan 2012 17:18:24 -0000 Quoth Mark Walters on Jan 20 at 12:10 am: > > Ok Having said this is trivial I have found a problem. What should > notmuch do if you do something like > > notmuch show id: > and that message is marked with a deleted tag? To be consistent with the > other cases (where a deleted message is in a matched thread) we might > want to return the message with the not-matched flag set (eg in > JSON). But my patch doesn't, as it never even sees the thread since it > doesn't match. > > Looking at notmuch-show.c I think we should not apply the exclude tags > to do_show_single, but usually should apply it to do_show. One solution > which is simple and is at least close to right would be to get do_show > to return the number of threads found. If this is zero then retry the > query without the excludes (possible setting the match_flag to zero on > each message since we know it does not match) > > This is not a completely correct solution as if you ask notmuch-show to > show more than one thread it might threads which only contain deleted > messages. > > I can't see other good possibilities without slowing down the normal > path a lot (eg find all threads that match the original query and then > apply the argument above). > > Any thoughts? Oh dear. Well, here's one idea. Instead of doing a single thread query in show, do a thread query without the exclusions and then a message query with the exclusions. Output all of the messages from the first query, but use the results of the second query to determine which messages are "matched". The same could be accomplished in the library somewhat more efficiently, but it's not obvious to me what the API would be. > Incidentally, is there something strange at the end of notmuch-show.c: I > can't see how we could ever reach the last half dozen lines. Yes, I've wondered about that before, too. I think none of those technically matter since they're all cleaning up resources that the OS is about to clean up for us. It would be a problem if the database was open in write mode because Xapian's write lock hangs around for a split second after the process terminates if you don't close the database yourself, but in read mode it doesn't take any locks. Not that this excuses the code.