Kyle schrieb am Montag der 27. Dezember 2021 um 21:20 -05:

> piem-lei-query shows unthreaded results.  From there,
> piem-lei-query-thread can be used to show the entire thread for that
> result.  This design is driven largely by my use of Notmuch, where I
> call notmuch-search and then follow up with a custom variant of
> notmuch-tree to show _one_ thread.
>
> However, users familiar with notmuch-tree probably expect to be able
> to display _multiple_ threads.  piem-lei-query--thread already returns
> a list of threads, so it really just needs to be exposed at the
> command level.
>
> Update piem-lei-query-thread to make it handle a general query,
> renaming it slightly to make it clearer that the command now supports
> displaying multiple threads.  Then, add a wrapper piem-lei-mid-thread
> that handles the old "single thread for a given MID" behavior.
>
> Rather than adding another suffix command to the lei-q transient
> (piem-lei-query-threads in addition to the existing piem-lei-query), I
> considered adding --threads to the transient and then having
> piem-lei-query check whether it's in the arguments.  Conceptually, I
> dislike that because it conflates threaded _display_ with lei's
> --threads behavior that's instead about whether to include other
> messages from a match's thread in the results.  Also, it'd mean some
> downstream handling of piem-lei-buffer-args (e.g., by
> piem-lei-query-show) would be complicated by the need to filter out
> --threads.
>
> Note that piem-lei-query-thread no longer sets piem-lei-buffer-mid
> because the buffer is no longer tied to a single message ID, which is
> okay because, unlike in show buffers, the value isn't actually used.
>
> Suggested-by: Xinglu Chen <public@yoctocell.xyz>
> Link: https://inbox.kyleam.com/piem/871r96am1q.fsf@yoctocell.xyz
> ---
>  piem-lei.el | 41 +++++++++++++++++++++++++++--------------
>  1 file changed, 27 insertions(+), 14 deletions(-)

The changes look good to me, and things work as expected.  Thanks for
the work!