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 1F0226DE0F46 for ; Tue, 26 Nov 2019 14:53:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.276 X-Spam-Level: X-Spam-Status: No, score=0.276 tagged_above=-999 required=5 tests=[AWL=-0.376, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NEUTRAL=0.652, UNPARSEABLE_RELAY=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 CiQgKQBj9QnI for ; Tue, 26 Nov 2019 14:52:58 -0800 (PST) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by arlo.cworth.org (Postfix) with ESMTPS id 4F9936DE0F44 for ; Tue, 26 Nov 2019 14:52:58 -0800 (PST) Received: by mail-wr1-f67.google.com with SMTP id z7so20997758wrl.13 for ; Tue, 26 Nov 2019 14:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dme-org.20150623.gappssmtp.com; s=20150623; h=to:cc:subject:in-reply-to:references:from:date:message-id :mime-version; bh=ih7cwXYtyE5r13IfQX3KN0pLC0YbrxBo2HVer2HYiHw=; b=A5SP2t5dnRm3Y5WB35M0mpQkxB5PjIlWhNFE6D4swy7/Y6c2i4DtgSsAlVWGS+yIkQ TAS98sSMtVv0bCOgg3pkjk5Jcm6sYZeAwXSWI83UfhNbu2+/FgzO5TzjVYlPsLe9l+f5 Ny9n0f/YWzHtAAC8Rrg0MBwtYenZO+o6VPhs0xMlETssU251E9n/YtEYXR69RDo1i+IJ rUtTaFP78+WMBaWwrJTUkyC3b+JgaTNNaVJqW6be2TI+93rd2oQ6IWGS52QVrgcQy1w/ oLahbGNGdZIGklLF8tV8ZKtowIW5w6/KCi3Q47bkNp7KVpezeAzNPAam/baJAvbC1zs4 dz9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:subject:in-reply-to:references:from:date :message-id:mime-version; bh=ih7cwXYtyE5r13IfQX3KN0pLC0YbrxBo2HVer2HYiHw=; b=r0cU90t8zkBuCKdIh7HwNETvC56XLqv1oBgM85DUYKIMnOhi0S/t8qlhy/7JI4IDfr 5ectY2047gMPuBG5hvtCDoTfa+ptY/UaFllwPZffZK0RqQyt84SSE2Mpf2EQc1Fc4tmI RScp9R8lQ6Iclt1OSt+EBDQgyyxZpit5f941agXt2+Qu+gTHR0X0XiWE22iwylMvk0Uw a9fnHKALphhRMksKRG+atlpHDVZjQHujnD+LuP1gfHuCF0A0fn/UySkphrcSy5YlOqu+ e0858kDRCYooBI72jGvh3W7q7tySPV/lSFuszfOqcf51LR1A5wzLULtkTGuh3UHHOhIL QmKQ== X-Gm-Message-State: APjAAAVI55AgTRA7yh+5n4F7ZchkWQXV4UaVnLh1tyFoUx1g9E50YV8l IS6QqOryjE7Ve6dHsUA0bP3oizoV+tM= X-Google-Smtp-Source: APXvYqzGSmT42q3gOIKb91hWcBPNaj36v/qcxOIdR8IVYcTXSphgPixo1rMmTm8PD51Ta6P9LRjuGw== X-Received: by 2002:adf:f709:: with SMTP id r9mr38251247wrp.8.1574808776751; Tue, 26 Nov 2019 14:52:56 -0800 (PST) Received: from disaster-area.hh.sledj.net (disaster-area.hh.sledj.net. [81.149.164.25]) by smtp.gmail.com with ESMTPSA id b1sm16674606wrs.74.2019.11.26.14.52.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Nov 2019 14:52:55 -0800 (PST) Received: from localhost (disaster-area.hh.sledj.net [local]) by disaster-area.hh.sledj.net (OpenSMTPD) with ESMTPA id 8e66551d; Tue, 26 Nov 2019 22:52:54 +0000 (UTC) To: Sean Whitton , emacs-orgmode@gnu.org Cc: notmuch@notmuchmail.org Subject: Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query In-Reply-To: <87r21u1et3.fsf@iris.silentflame.com> References: <87h82wrjvb.fsf@iris.silentflame.com> <87r21u1et3.fsf@iris.silentflame.com> X-HGTTG: zarniwoop From: David Edmondson Date: Tue, 26 Nov 2019 22:52:54 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 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: Tue, 26 Nov 2019 22:53:01 -0000 --=-=-= Content-Type: text/plain On Tuesday, 2019-11-26 at 14:57:28 -07, Sean Whitton wrote: > On Tue 26 Nov 2019 at 08:05PM +00, David Edmondson wrote: > >> Could you explain how you were using `notmuch-show-thread-id' in a way >> that was broken by the presence of an arbitrary query? > > I've observed that the standard notmuch command > `notmuch-show-filter-thread' doesn't work in a buffer opened by > `org-notmuch-follow-link'. The poor behaviour is just a side effect of the way that queries are composed to implement the filter functionality. Does the attached patch help? > Further, my package 'mailscripts' tries to pass the current value of > `notmuch-show-thread-id' to notmuch-extract-patch(1). > > https://git.spwhitton.name/mailscripts/tree/mailscripts.el#n72 > > https://manpages.debian.org/notmuch-extract-patch > > If `notmuch-show-thread-id' contains a query which returns a single > message, the wrong value is passed to notmuch-extract-patch(1), such > that it may not extract all of the patches in the thread. It's not clear to me that this is broken. notmuch-extract-patch seems to be properly extracting patches from the messages that match the query. If the current `notmuch-show' buffer query doesn't match the entire thread, why should `notmuch-extract-thread-patches' be expected to apply patches from the whole thread? --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=query-composition.patch diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index e13ca3d7..ecbc03d2 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1311,7 +1311,7 @@ and THREAD. The next query is THREAD alone, and serves as a fallback if the prior matches no messages." (let (queries) (push (list thread) queries) - (if context (push (list thread "and (" context ")") queries)) + (if context (push (list "(" thread ") and (" context ")") queries)) queries)) (defun notmuch-show--build-buffer (&optional state) --=-=-= Content-Type: text/plain dme. -- I can't explain, you would not understand. This is not how I am. --=-=-=--