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

[David Edmondson]

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

>>> 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?
>
> 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.

> (I note that this is a mailscripts design question, not strictly
> relevant to the issue of ol-notmuch.el causing the
> notmuch-show-thread-id variable to be mispopulated.  Thank you for your
> engagement with mailscripts, regardless!)

Well, I'm interested in the functionality that it provides :-)

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

dme.
-- 
Hello? Is anybody home? Well, you don't know me, but I know you.