On Tue 26 Nov 2019 at 08:17PM +01, ra...@free.fr wrote:

> Your approach probably works most of the time, but I don't like the idea
> of having to perform 2 queries when one should be enough.
> I think a better approach would be to change notmuch-show (or add a
> new version) that would allow taking arbitrary queries (and
> especially, message ids) as input. This probably used to be the case.
> Note that the command line notmuch show function does accept arbitrary
> search terms as an argument
> I think updating notmuch-show to compute the thread id from the query
> (instead of assuming that the input is a thread id) would be the best
> way to go, but you should see that with the notmuch developers.

I agree with you that it would be best if `notmuch-show' were extended
to accept arbitrary notmuch queries instead of only thread IDs.

However, I also believe that ol-notmuch.el should be updated in the
meantime.  notmuch.el presently exposes an API, `notmuch-show', which
takes a thread ID.  ol-notmuch.el is misusing that API by passing in a
value of a different type -- a notmuch query rather than a thread ID.

That's a bug: even if an API is more limited than we would like it to
be, we should use it in the way that it is documented to be used by its

This misuse of the API causes numerous other hard-to-diagnose bugs.  For
example, if you use `org-notmuch-follow-link' to open an Org-mode link
like "notmuch:id:f...@bar.baz", the standard notmuch command
`notmuch-show-filter-thread' doesn't work.  And if you use `C-u c i` to
yank the thread ID for pasting into a shell, say, you will yank a value
which is not a thread ID.

Sean Whitton
notmuch mailing list

Reply via email to