Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

[Sean Whitton]

[dropping Org-mode list per David's suggestion]

Hello,

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-count)
      (interactive "P")
      (let ((subject-filter
             (if reroll-count
                 (let ((n (prefix-numeric-value reroll-count)))
                   (if (= n 1)
                       "(subject:/\\[.*PATCH[^v]*\\]/ or subject:/\\[.*PATCH.*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.

>> 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 :)

> Presumably this all arises because thread IDs are neither stable nor
> portable, so they are inappropriate to store in an external document (as
> an org-mode link in this case)?

Indeed.

-- 
Sean Whitton