From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:863f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms12 with LMTPS id kF9kLkQryGDzHwAAsNZ9tg (envelope-from ) for ; Tue, 15 Jun 2021 04:23:32 +0000 Received: from out1.migadu.com ([2001:41d0:2:863f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id gOQTFEEryGCDQAAAB5/wlQ (envelope-from ) for ; Tue, 15 Jun 2021 04:23:29 +0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1623731009; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zXGlH0+/8KBrtAztUBP4l+yUqmtTulYxjb7qn/o5mB4=; b=tIyjo17EsaNas0ZqUcEGjxEH7tbmJk4irTeWRPf/cWmyUUibjjAQvAfvmkJrBdt6/IfehF IWHNlTY9GFrtW25jPi2tyTK+qXT9cvExtjIofPBFDYzE0nWboBlgiNsiTIz8cHGr66Xmf3 Ke85bStrk9yU6NZSLOO8HLhQPCIIi9RURNKJ4tTAt2zQrZGKvS0nOzuIYBB9iyydSi9Ske vb/Da/26TeJlJhBBTT4wWVRVC+I3pUHUTfG4O13t6XmXZQXhFPk/Oq/q7lCncXppOwWRzL KP3a+3loPp362ewJ1a1qNDsd8xADYQ2+zTEyI0cmKkMIdp0kTZ9nTv/o3y2A9g== From: Kyle Meyer To: Xinglu Chen Cc: piem@inbox.kyleam.com Subject: Re: Thoughts and feedback on piem-lei In-Reply-To: <871r96am1q.fsf@yoctocell.xyz> References: <871r96am1q.fsf@yoctocell.xyz> Date: Tue, 15 Jun 2021 00:23:27 -0400 Message-ID: <87r1h3lps0.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: kyle@kyleam.com X-TUID: uUhsi9rDjF6R 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 =E2=80=98piem-lei-query=E2=80=99 was a little slow, at l= east compared > to notmuch.el. I have indexed the guix-devel and guix-patches mailing > lists (I think) and making the query =E2=80=98d:20.days.ago.. guix=E2= =80=99 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 =E2=80=98git log=E2=80=99. 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 =E2=80=98lei blob OID=E2=80=99 attach= ment, not sure > why that is there [...] > [-- Attachment #1: Type: text/plain; charset=3D"UTF-8", Size: 5599 byte= s --] > [-- lei blob 69667b191433ea4c4a46dd8414a4c5ee366d8e4d:1 --] That's what `lei q --format=3Dtext ...' outputs. The plan is to eventually process the raw buffer (e.g., mm-dissect-buffer), but --format=3Dtext was an easy way to get things off the ground. > * One slight annoyance is that pressing {q} in the =E2=80=98lei-query=E2= =80=99 buffer > just hides the buffer itself, so I end up with two windows, one with a > =E2=80=98lei-show=E2=80=99 buffer and another one with some random buff= er I happen > to have open before I invoked =E2=80=98piem-lei-query=E2=80=99. In not= much.el, > pressing {q} in the =E2=80=98notmuch-tree=E2=80=99 buffer first hides t= he > corresponding =E2=80=98notmuch-show=E2=80=99 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 =E2=80=98notmuch-tree=E2=80=99 view, would it make sen= se 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 =E2=80=98piem-lei-query-thread=E2=80=99? 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=E2=80=99t 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.