MH & thread support

MH & thread support

[Jakub Kicinski]

Hi!

Two questions:

 - how do the plans for MH email format support look? It'd be great to
   fetch emails with lei directly to claws-mail (which seems to be used
   by a number of kernel devs, at least)

 - is there a way to get lei to fetch a particular thread? It seems
   like using a bare msg-id as the search term mostly works, but it 
   also fetches in any threads which were referring to the thread of
   interest by posting a link

Thanks for great work!

Re: MH & thread support

[Kyle Meyer]

Jakub Kicinski writes:

> Hi!
>
> Two questions:
>
>  - how do the plans for MH email format support look? It'd be great to
>    fetch emails with lei directly to claws-mail (which seems to be used
>    by a number of kernel devs, at least)

I don't have any informed opinions on this and don't know what Eric's
thoughts are, but fwiw this is what he wrote in lei-mail-formats(5):

  MH
         Not yet supported, locking semantics (or lack thereof) appear to make
         it unsuitable for parallel access.  It is widely-supported by a variety
         of MUAs and mailing list managers, however.

>  - is there a way to get lei to fetch a particular thread? It seems
>    like using a bare msg-id as the search term mostly works, but it 
>    also fetches in any threads which were referring to the thread of
>    interest by posting a link

You can search with the "mid:" prefix and then pull in the entire thread
with -t/--threads:

  $ lei q -f ldjson \
    mid:20211119204916.grergcuzj5gcic6c@meerkat.local | \
    jq '[.blob,.s,.f[0][0]]'
  [
    "7e49832370e95afb54298d21ea4c10d338bb3a7b",
    "RFC: should lei inject its own \"Received:\" header?",
    "Konstantin Ryabitsev"
  ]


  $ lei q -t -f ldjson \
    mid:20211119204916.grergcuzj5gcic6c@meerkat.local | \
    jq '[.blob,.s,.f[0][0]]'
  [
    "7e49832370e95afb54298d21ea4c10d338bb3a7b",
    "RFC: should lei inject its own \"Received:\" header?",
    "Konstantin Ryabitsev"
  ]
  [
    "70c49f363594e94d89a14bcb57c45d45cac49172",
    "Re: RFC: should lei inject its own \"Received:\" header?",
    "Eric Wong"
  ]

Re: MH & thread support

[Jakub Kicinski]

On Thu, 06 Jan 2022 20:40:09 -0500 Kyle Meyer wrote:
> >  - is there a way to get lei to fetch a particular thread? It seems
> >    like using a bare msg-id as the search term mostly works, but it 
> >    also fetches in any threads which were referring to the thread of
> >    interest by posting a link  
> 
> You can search with the "mid:" prefix and then pull in the entire thread
> with -t/--threads:
> 
>   $ lei q -f ldjson \
>     mid:20211119204916.grergcuzj5gcic6c@meerkat.local | \
>     jq '[.blob,.s,.f[0][0]]'
>   [
>     "7e49832370e95afb54298d21ea4c10d338bb3a7b",
>     "RFC: should lei inject its own \"Received:\" header?",
>     "Konstantin Ryabitsev"
>   ]
> 
> 
>   $ lei q -t -f ldjson \
>     mid:20211119204916.grergcuzj5gcic6c@meerkat.local | \
>     jq '[.blob,.s,.f[0][0]]'
>   [
>     "7e49832370e95afb54298d21ea4c10d338bb3a7b",
>     "RFC: should lei inject its own \"Received:\" header?",
>     "Konstantin Ryabitsev"
>   ]
>   [
>     "70c49f363594e94d89a14bcb57c45d45cac49172",
>     "Re: RFC: should lei inject its own \"Received:\" header?",
>     "Eric Wong"
>   ]

Perfect, thanks!

Re: MH & thread support

[Eric Wong]

Kyle Meyer <kyle@kyleam.com> wrote:
> Jakub Kicinski writes:
> >  - how do the plans for MH email format support look? It'd be great to
> >    fetch emails with lei directly to claws-mail (which seems to be used
> >    by a number of kernel devs, at least)
> 
> I don't have any informed opinions on this and don't know what Eric's
> thoughts are, but fwiw this is what he wrote in lei-mail-formats(5):
> 
>   MH
>          Not yet supported, locking semantics (or lack thereof) appear to make
>          it unsuitable for parallel access.  It is widely-supported by a variety
>          of MUAs and mailing list managers, however.

Yeah, read-write is tricky since I don't know how parallel writers
handle sequence numbers or message flags w/o stepping over each other.
Write-to-temp-file-then-rename means one of the renamers loses...

Read-only is more likely, maybe...  I fear I'm too drain bamaged :<
And whatever gets added ends up being support a burden forever.