Thoughts and feedback on piem-lei

Thoughts and feedback on piem-lei

[Xinglu Chen]

[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]

Hi,

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

* 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’.

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

* In PGP singed messages there is a ‘lei blob OID’ attachment, not sure
  why that is there

  --8<---------------cut here---------------start------------->8---
  # kw:seen
  From: Maxime Devos <maximedevos@telenet.be>
  To: David Dashyan <mail@davie.li>, Guix Help <help-guix@gnu.org>
  Subject: Re: Bug? Importing (gnu rest ...) fails due to lack of patch files on build side.
  Date: Sun, 25 Apr 2021 18:24:57 +0200
  Message-ID: <f2aa26f2fba3e080bd528c0ab10ebb121483aac4.camel@telenet.be>
  In-Reply-To: <87blajj0kh.fsf@davie.li>
  
  [-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5599 bytes --]
  [-- lei blob 69667b191433ea4c4a46dd8414a4c5ee366d8e4d:1 --]
  
  [...]
  --8<---------------cut here---------------end--------------->8---

  and at the end of the message

  --8<---------------cut here---------------start------------->8---
  Greetings,
  Maxime
  [-- Attachment #2: This is a digitally signed message part --]
  [-- Type: application/pgp-signature; name="signature.asc", Size: 260 bytes --]
  [-- lei blob 69667b191433ea4c4a46dd8414a4c5ee366d8e4d:2 --]
  --8<---------------cut here---------------end--------------->8---

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

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

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

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!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: Thoughts and feedback on piem-lei

[Kyle Meyer]

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.

Re: Thoughts and feedback on piem-lei

[Xinglu Chen]

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]

On Tue, Jun 15 2021, Kyle Meyer wrote:

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

You are welcome!

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

Hmm, it does seem to get a bit faster on the second run, thanks for
pointing this out.

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

Ah, OK, you can probably tell that I haven’t used lei that much :)

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

No worries, no need to hurry :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]