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 D0CC76DE0B6D for ; Tue, 26 Nov 2019 09:41:59 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -2.762 X-Spam-Level: X-Spam-Status: No, score=-2.762 tagged_above=-999 required=5 tests=[AWL=-1.862, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, 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 n8z_EkeVRDk1 for ; Tue, 26 Nov 2019 09:41:57 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by arlo.cworth.org (Postfix) with ESMTPS id F36AC6DE09ED for ; Tue, 26 Nov 2019 09:41:56 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1572C22741; Tue, 26 Nov 2019 12:41:54 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 26 Nov 2019 12:41:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=fm1; bh=y4I60Mb9sUszoWf+MInKhZLJGJ U+EpnEZ/+BTdfDTTc=; b=GbwZs1wYcpGdf3Lw5HAYaiw+DpCK2imY8U2p4GsddT r8DtRIz1FB6LhNuhG08u5FOwoJqB3FrWsDZ3mA+mKOiOpCh2M4dsmsmrsaKRkJT0 hGHB09DQl0lfkVLY7h/rDa8wX07iw0J2uD5iTJCjSBDNv9u+lJQZw7ywf2qVKIuE l9UXXeARSyHMRr/aWd4t3g115hGpHrZnegCLXl7AZWoOTmcvV6jf1wa6A3rQHhjS EiyAQy3NZLZcHiXVlTvJztJwFywjiS3aH+DL4M4L0X6dBzuZEz0opwO6DmbAAUsY YSgnvxuZHnxAtg2IiNxG87yfj29kfGLwjGtqsOl7BOBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=y4I60M b9sUszoWf+MInKhZLJGJU+EpnEZ/+BTdfDTTc=; b=q416HtnjNXiORHGGjzu7PW aZTntiO8bVYO5+A+lSBY9hk9uXq0f22IiM53+pWKnRdMCe1rtfzVdArb9A2i94dP EEHpDgAQ73QHKx+VRi7UxD8ZUec6obLjihuMojp833T6eyYwpFGQhlkiCTSIKQRU s2s/tcz2Zg43o1gobRvk7B0s32O3Y6seCqfXYkZjuDUFVfTtAro4a05L6No86puD EG0/ccvm9GelXaCOcjp+AWiEDAIcZQ5r+gI1Q8xH+qwF1rQv2jJmCz0ExZ9aCQ57 uDmPaaCe1ccyRcQzR4XUVktOTVqoaO6m7oUz/NIc0jFd5FIQPpeqXNT0xpfMaGGg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeifedguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufgjfhffkfggtgesthdtre dttddttdenucfhrhhomhepufgvrghnucghhhhithhtohhnuceoshhpfihhihhtthhonhes shhpfihhihhtthhonhdrnhgrmhgvqeenucffohhmrghinhepvhgrrhhirggslhgvrdhorh hgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsphifhhhithhtohhnsehsphifhhhithht ohhnrdhnrghmvgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: From: Sean Whitton To: emacs-orgmode@gnu.org, Matthieu Lemerre Cc: notmuch@notmuchmail.org Subject: Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query In-Reply-To: <87h82wrjvb.fsf@iris.silentflame.com> References: <87h82wrjvb.fsf@iris.silentflame.com> Date: Tue, 26 Nov 2019 10:41:51 -0700 Message-ID: <87y2w21qn4.fsf@iris.silentflame.com> MIME-Version: 1.0 Content-Type: text/plain 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 17:42:00 -0000 Dear maintainers, On Thu 21 Nov 2019 at 02:37PM -07, Sean Whitton wrote: > The function `org-notmuch-follow-link' in {org,ol}-notmuch.el calls > `notmuch-show' with an arbitrary notmuch search query. However, the > docstring for `notmuch-show' specifies that a notmuch thread ID, rather > than an arbitrary notmuch query, should be supplied to `notmuch-show'. > > The effect of this is that the variable `notmuch-show-thread-id' may > contain an arbitrary search query rather than a thread ID. That broke > some code of mine which uses that variable. > > `org-notmuch-follow-link' needs to continue to accept an arbitrary query > (as notmuch thread IDs are not stable), but it should convert it to a > thread ID before passing it to `notmuch-show'. Here is my workaround. If this approach seems sensible I can prepare a patch to `org-notmuch-follow-link` in ol-notmuch.el. (use-package org-notmuch :init ;; the default value for `org-notmuch-open-function' is ;; `org-notmuch-follow-link', but that function is broken: it calls ;; `notmuch-show' with a search query rather than a thread ID. This ;; causes `notmuch-show-thread-id' to be populated with a value ;; which is not a thread ID, which breaks various other things ;; ;; so use a custom function instead (defun spw--org-notmuch-follow-link (search) (let ((thread-id (substring (shell-command-to-string (combine-and-quote-strings (list "notmuch" "search" "--output=threads" "--limit=1" "--format=text" "--format-version=4" search))) 0 -1))) (notmuch-show thread-id nil nil search search))) (setq org-notmuch-open-function 'spw--org-notmuch-follow-link)) -- Sean Whitton