Re: Thoughts and feedback on piem-lei

[Kyle Meyer <kyle@kyleam.com>]

Xinglu Chen writes:

> Hi,
>
> I played around with the lei interface for a bit, and I have some
> thoughts and observations:

Thanks a lot for writing this up.

> * I noticed that ‘piem-lei-query’ was a little slow, at least compared
>   to notmuch.el.  I have indexed the guix-devel and guix-patches mailing
>   lists (I think) and making the query ‘d:20.days.ago.. guix’ took
>   around three seconds.  It seems like it waits for all the results from
>   lei to arrive before processing them, whereas notmuch.el processes the
>   messages as they come, similar to ‘git log’.

Right, piem-lei-query waits for the entire output.  Moving to an
asynchronous process is definitely a direction I'd like to go.  Offhand
I think lei-q's ldjson format should be amenable, but I haven't started
looking into it yet.

Also, I'd be curious how much of a speedup you see on the second run.
From the command line, I've noticed it sometimes takes lei-q a bit of
time before outputting anything at all, and that it's much faster on the
second run of the query.  If that's the main source of the slowdown,
async processing on piem's end of course won't help.

> * I like how the interface resembles the Web interface, especially the
>   threaded view.

Glad to hear it.  (Also, it should be pretty easy to add an option for
an alternative formatter.)

> * In PGP singed messages there is a ‘lei blob OID’ attachment, not sure
>   why that is there
[...]
>   [-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5599 bytes --]
>   [-- lei blob 69667b191433ea4c4a46dd8414a4c5ee366d8e4d:1 --]

That's what `lei q --format=text ...' outputs.  The plan is to
eventually process the raw buffer (e.g., mm-dissect-buffer), but
--format=text was an easy way to get things off the ground.

> * One slight annoyance is that pressing {q} in the ‘lei-query’ buffer
>   just hides the buffer itself, so I end up with two windows, one with a
>   ‘lei-show’ buffer and another one with some random buffer I happen
>   to have open before I invoked ‘piem-lei-query’.  In notmuch.el,
>   pressing {q} in the ‘notmuch-tree’ buffer first hides the
>   corresponding ‘notmuch-show’ window.

Good point, sounds like an improvement to me.  (I haven't really given
much thought to the layout, aside from wanting all buffer handling to
play well with display-buffer-* configuration.)

> Some questions that poped into my mind:
>
> * I quite like the ‘notmuch-tree’ view, would it make sense to have
>   something similar if piem so one could display multiple threads in one
>   buffer, instead of just display a single thread (unless I haved missed
>   something) like ‘piem-lei-query-thread’?

Hmm, while I do use notmuch-tree, I guess I've never really found it
useful to display multiple threads (i.e. I usually call it from a show
rather than search buffer).  You're right that that's not currently
possible, but piem-lei-query--thread should return multiple roots, so I
_think_ the underlying pieces are already there.

> * Since piem is not an MUA, will there be any support for sending
>   messages, or will users be expected to use {M-x compose-mail} or
>   something?

I haven't thought about it in detail, but I do want to support replying
and was planning to study notmuch-mua.

> Those are some thing I had in mind, sorry if the message got a bit long
> :)  I don’t know if I will be able to send patches, but I really like
> what I am seeing so far, thank you for the work!

Thanks again for the feedback.  My free time is a bit crunched at the
moment, but some of these should be next-ish steps when I get back to
working on piem-lei.