Re: [Nmh-workers] A script for threading

[Joel Reicher]

> Joel Reicher wrote:
> >Sequences *appear* to be the right sort of thing for thread display and
> >navigation
> 
> I still think the fact that they're restricted to numerical ascending
> order makes them useless for a serious threading implementation.

Not sure I understand this point, but perhaps the confusion is resolved
below.

> >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.
> 
> Isn't that broken because it will sort an entire thread tree by
> date (say) rather than by thread and then only by date within
> siblings?

Not what I had in mind. The kind of code I'm playing with (and I'm sorry
I haven't posted it yet) does a depth-first recursion through the
thread tree displaying scanlines. This is what you'd expect. The order
in which the siblings at any given level of recursion are iterated over
is, at the moment, determined by message numbering. This means that
the sibling ordering *within* the thread display corresponds to the
ordering of messages in the folder. I like the synchronicity of that,
but perhaps it's not such a significant idea.

One of the reasons it's come out this way is that I'd decided to
save the thread structure as the sequence-like data
parent: sibling sibling sibling ...

The thread navigation commands I've coded are "up" and "down". These
two commands have the concept of a "current sibling list", and save it
as a sequence when they're executed. down, by default, changes the
current message to be the first in the new sibling list. up, on the
other hand, sets it to be the parent of the old current message, which
could be anywhere within the new sibling list.

As you can see, navigation within the sibling list, because it's a
sequence, will be determined by the existing order of messages in the
folder.

I put it to you that my choice of thread navigation is what is "most"
orthogonal to the existing navigation in MH.

> I think that if you want to keep the threading support out of the main
> nmh utilities (scan/show/etc) you need to at least add an option to them
> to respect the order of message numbers on the command line.

I'm trying to craft something that complements/supervenes-on the existing
MH semantics. So I don't want to contradict existing MH semantics either,
and no MH commands respect command line order of message numbers at the
moment, AFAIK. This has been a contentious issue in the past, though,
I believe.

> (But I still think that actually having the core utilities know about
> threads would be better, in the same way that it's more convenient for
> them to all know about syntaxes like '4-5', 'last:20', etc.)

I don't think that will be necessary. Finding the orthogonality I wanted
hasn't been difficult. It seems to be quite natural. What might be better
is to make these new commands, if they work well enough, part of the
core.

Cheers,

        - Joel