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 44D7D6DE0F60 for ; Wed, 27 Nov 2019 12:52:45 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.274 X-Spam-Level: X-Spam-Status: No, score=0.274 tagged_above=-999 required=5 tests=[AWL=-0.378, 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 1yQgE8ZRkj7I for ; Wed, 27 Nov 2019 12:52:43 -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 D1C6B6DE0F51 for ; Wed, 27 Nov 2019 12:52:43 -0800 (PST) Received: by mail-wr1-f67.google.com with SMTP id z3so28340109wru.3 for ; Wed, 27 Nov 2019 12:52:43 -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:content-transfer-encoding; bh=HHyEtaMEOxFrVOCDEs97tKzNRaEFUbiRIJGK4cnsF7Q=; b=Pt1+EklXK+SbaqbT42aI917BP10KsVgIX0EqYW7fFfxeABek6OhPfZOCOfTbTJ7g5f oytDkDWP00GLd+G6gE+zcSpR7t9aMxB6PhhAU4yOt6DcnPsPqiEPmvIl66bT+hlqjiYo EzWAwcF1IA2YyPpzSoMD+f7qc/qlhFJNBP0N2pfbEat8N1NqyWAIubJVxUGOe97LS22H qoeTYO7Fj+lk8SczoFTTk38oU184PJLgQbWPimnbhrbj//4VdHQDIHAmmGjaiOm6ES06 ItYXyio2mJ8IqWfBtoNiW5juozzM+x8AOfTSoVW6fSxxNu1XuD4iMbRz8OfEM7fAhD9i CFIQ== 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:content-transfer-encoding; bh=HHyEtaMEOxFrVOCDEs97tKzNRaEFUbiRIJGK4cnsF7Q=; b=E+j8eIUTJPv9GEd6s1lYBAgG1pP3+Mz18x9FBjaguiG0rxVJWAcjqMhD0gIsW/eA1a XtEyrJw7jgNHPHAzsYME2UbRy2ClyWUswsHY7Km5/SMjYpUJWFJqGIo6zMJ/HJXmster bmFcA8/M+s0DkWD/ki4unKNCHdHpyHDbXWKdXR8OgqMiAQSoIURVANrMK7eFHqYf2dLS tmfXo/gX/yUH2aJc+1VITjJzV/jE7VsacZgHJ/HLvFPpCDSgMHb5MreIaykBjDUJ0foK EQAGEmWjfZ96Js9tVkmU1+R4Rb0sgTt6MU8kbjGl1i1xCiSwNBuE1oKE6GL/H1FDYLHq 3/cA== X-Gm-Message-State: APjAAAUA3LvHgcTLK8gKOmnxrYW3owiTy+HCEQpim0Mk1D8Phnl7o3Rq AXmueC3zOPgwumHAExILEmfkPQ== X-Google-Smtp-Source: APXvYqwCVzVQaHj3dDGFccGZiwWXz28SlX6UZzi+w5s7JEszJ98cr0mpW4CaKQIdbjaVHCxKHaIaDQ== X-Received: by 2002:adf:d844:: with SMTP id k4mr43164342wrl.333.1574887961885; Wed, 27 Nov 2019 12:52:41 -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 g207sm8812292wmg.40.2019.11.27.12.52.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Nov 2019 12:52:41 -0800 (PST) Received: from localhost (disaster-area.hh.sledj.net [local]) by disaster-area.hh.sledj.net (OpenSMTPD) with ESMTPA id d8b59725; Wed, 27 Nov 2019 20:52:40 +0000 (UTC) To: Sean Whitton Cc: notmuch@notmuchmail.org Subject: Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query In-Reply-To: <87d0ddz04c.fsf@iris.silentflame.com> References: <87h82wrjvb.fsf@iris.silentflame.com> <87r21u1et3.fsf@iris.silentflame.com> <875zj61aqe.fsf@iris.silentflame.com> <87d0ddz04c.fsf@iris.silentflame.com> X-HGTTG: zarniwoop From: David Edmondson Date: Wed, 27 Nov 2019 20:52:40 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Wed, 27 Nov 2019 20:52:45 -0000 On Wednesday, 2019-11-27 at 10:42:59 -07, Sean Whitton wrote: > On Wed 27 Nov 2019 at 01:08PM +00, David Edmondson wrote: > >> On Tuesday, 2019-11-26 at 16:25:29 -07, Sean Whitton wrote: >> >>> On Tue 26 Nov 2019 at 10:52PM +00, David Edmondson wrote: >>> >>>> 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? >>> >>> Unfortunately, it is still broken in my test case. >> >> Could you describe your test case please? (We could remove emacs-orgmode >> for that conversation if you think it appropriate.) > > I have this function which calls notmuch-show-filter-thread: > > (defun spw--notmuch-show-filter-thread-patches (&optional reroll-coun= t) > (interactive "P") > (let ((subject-filter > (if reroll-count > (let ((n (prefix-numeric-value reroll-count))) > (if (=3D n 1) > "(subject:/\\[.*PATCH[^v]*\\]/ or subject:/\\[.*PA= TCH.*v1.*\\]/)" > (concat "subject:/\\[.*PATCH.*v" (number-to-string n= ) ".*\\]/"))) > "subject:/\\[.*PATCH.*\\]/ "))) > (notmuch-show-filter-thread > (concat "tag:unread or tag:flagged or (" > subject-filter > " and not subject:'Re:' and not subject:'Info received')= ")))) > > Copy-pasting the whole function since you mentioned you were interested > in the notmuch patch review functionality I'm working on, but let me > know if you want a narrower test case. If this does what I think, which is to filter the current thread to show only those messages that contain actual patches (with an optional version number), then, with the previous patch I sent, it seems to work just fine for me if the original `notmuch-show' query is something like =E2=80=9Cthread:a or thread:b=E2=80=9D, where those threads both contain bo= th patches and comments on the patches. An example call I used initially is: (notmuch-show "thread:{id:20191117222929.1064-1-jb55@jb55.com} or thread:{i= d:20190419035659.28961-1-congdanhqx@gmail.com}") Hopefully this is a query that will work for you as well. Limiting this using your function behaves as I would expect. It's a lot to ask, I know, but if you could provide a specific set of messages with a corresponding initial query that fails for you after limiting using your function, it would be helpful. >>> The purpose of `notmuch-extract-thread-patches' is to extract a whole >>> git-send-email(1) patch series at a time, because that is usually what >>> one wants to do. There are `notmuch-extract-message-patches' and >>> `notmuch-show-pipe-message' for single patches. >> >> Then I think the approach that you have (wrapping the query in >> thread:{}) makes perfect sense. > > To my mind, it makes sense only to the extent that committing hacky > workarounds is something which makes sense :) Well, if we stick to the idea that the first argument to `notmuch-show' can only be a thread ID, then yes. Given that thread IDs have some annoying properties, it would be convenient to allow the caller to pass an arbitrary query. If we fix anything that is broken by that, I'm happy to provide a patch that changes the code (and any implicit or explicit documentation) accordingly. dme. --=20 This is the time. This is the record of the time.