packages with binaries

[Stephen J. Turnbull]

Uday S Reddy writes:

 > So, you would sort the roots of all threads by the requested sort order,
 > then sort the children of each root, and then their children and so on,
 > recursively?

Nope.  Recursively, yes, but depth-first.

 > I figured out a way to incorporate everything in just one sort applied to
 > all messages (I still do remember how people used to sort punched cards in
 > the old days!)

Sure, there was an article about it in Martin Gardner's "Mathematical
Recreations" column in Scientific American in about 1967. :-)

 > and it became straightforward.

Yes and no.  Sorting is indeed straightforward, except for the fact
that you have to define a separate function which reorders the sort
keys (specifically, to always put the thread "key" first), and you now
have to call a threading function in the sort code.

 > I think I would call this clean and elegant, rather than "complex".

I guess we'll have to differ on that.

 > I am not sure I understand how the Internet comes into the picture.

It's the largest relevant referent for "universe" in this context. :-)

 > However, you would need to address the problem of reclaiming the
 > thread tree nodes of the folders that have been quit, basically
 > rolling out your own memory manager for the thread trees.  So, that
 > doesn't come for free!

Why do you have to reclaim anything?  As I said in my previous post,
the thread forest is universal, although the view VM has is missing a
lot of nodes.  See next point.

 > Indeed.  But, as you observed earlier, building the thread-tree is not all
 > that expensive.  So, doing it as part of virtual folder creation is quite
 > acceptable.  

Except that you sacrifice information, specifically about the messages
that aren't in the virtual folder.  If you build from scratch, those
messages' ids will correspond to empty containers, although they are
available to VM in real folders.  If you keep a global database, when
you quit a real folder, the implementation could note on the container
which folder(s) the message was found in, and fetch it when you say
"go to parent" in a sparse virtual folder even if the required real
folder isn't in the session any more.  I think that would be useful.

This information could even be kept in an external database (don't
tell Jamie I said that, he'd rise up out of his coffin before sunset
and throttle me! or at least call me "Wormhead" :-) so that you'd know
about all messages you ever threaded.

 > One worry is that the cycles in the thread tree might get resolved
 > differently each time, and that might confuse the user.

Do you really find cycles in the thread graph that often?  (The point
is not that you don't have to deal with them, of course, you do.  The
point is that if they're rare, user confusion will be even more so,
since not all cycles would confuse the user if broken differently.)

 > When I wrote out the invariants for the data structure, they turned
 > out to be longer than a screenful.

Hm.  I have a couple of checks for invariants on the thread forest
(eg, a non-root node must be a member of its parent's children, and
and each of a nodes' children must have it as the parent), and on the
root set (every member must have no ancestors with messages available
in a real folder in the session).  But that's about it.

I've seen the various conditions you've been adding in comments in
vm-thread.el, but they're very low-level (and in many cases I couldn't
figure out why they were imposed with less than a minute's thought for
each -- since there are several dozen, really understanding all that
would take hours, I suspect).