Re: [Nmh-workers] Threads

[Ken Hornstein]

>> In fact, the whole concept of 'threads' is something I would like to
>> keep outside of the base toolset.
>
>It's too complex to leave outside of nmh's knowledge.  I'd like to pick
>the parents of these messages, all ancestors, the immediate descendants,
>or all descendants, or all messages in the same thread, ideally combined
>with pick's, or its replacement's, other options.

Right, I'm kinda with you there; nmh needs to do something, but I'm not
sure what yet.  In my mind there are three possible things people mean
when they talk about "threading":

- The actual implementation of building the threading information.  There
  is some conflict here about how when it's done, how it's stored, but
  I think there isn't too much disagreement on what needs to be done.
  I hadn't seen jwz's writeup about that, but it looks pretty much exactly
  what we need to do.  That's relatively easy (well, straightforward, at
  least).  However, I think the issue with us isn't CPU time, it's io-ops.

- The user interface: how do we give threading information to users?  Have
  mhl(1) display a trn-style message tree? (which I admit that I was always
  partial to?).  Is it only via pick?  Indent subject lines in scan? (which
  to me throws away some of the useful information).

- (Optional) How do users navigate or select messages across a thread?  One
  thing I always liked about the trn display was that the messages were
  numbered and you could pick them via the number in the thread display.
  We can't really do that, but something similar would be nice.

--Ken