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
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers