Re: [Nmh-workers] A script for threading

[Joel Reicher]

> it occurred to me yesterday that this script might be quite
> useful (instead of just pretty :-) if it had one simple feature: 
> the ability to add each thread to a separate, temporary, mh
> sequence ("t1", "t2", "t3", ...). 

I've already been working on something a bit like this and was waiting
until it was more mature before saying anything, but now's a good time
to bring up a central problem. From mark(1)

       o Only a certain number of sequences may be defined for a given folder.
         This number is usually limited to 26 (10 on small systems).

Sequences *appear* to be the right sort of thing for thread display and
navigation, but they're really not suited to heavy duty use. I've been
arguing with myself about whether that's reasonable. The original intention
is that sequences be stored in a simple text format so that other software
could be written that manipulates them without difficulty, but then
refile, sortm, rmm, etc. become that little bit slower as they have to
update the sequences, or at the very least check if anything needs
updating. Consequently, it's not a good idea to have lots of sequences.

It is very easy to write out a sequence-like file, but then you don't
get the rather nice feature that the "sequence" remains correct even
when the messages get reordered. This is especially nice for threading
because using sequences would enable changing sibling orders by changing
the sorting of the entire folder. No respinning needed.

Even using storage more sophisticated than a text file, such as a hash
table or btree, doesn't solve this update problem. There are still
potentially many records (sequences) to update. Without getting too
whacky, about the only fast way I can think to do sequences is by having
them as a list of inodes.

Thoughts?

Cheers,

        - Joel