>> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
