Re: packages with binaries
Stephen J. Turnbull writes:
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 do add the thread "key" first if threading is turned on, but there no
reordering. In typical use of VM, threading would not be among the global
sort keys.
And, as you know, I don't lose sleep over calling functions. (I believe in
structured programming and information hiding, but the rest of software
engineering, I regard as a bunch of dogma to be taken with a large grain of
salt. But, still, you have evoked my interest in coupling issues and I will
continue to think about them.)
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.
In typical use of VM, we are using a bunch of current folders, and
occasionally we need to go search for something in the archived mail. If
the thread database grows as soon as you load archived folders, never to be
reclaimed, then that might degrade performance. As you might have seen,
memory leakage is a serious concern in the FSF Emacs world right now.
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.
Yes, that seems like a useful extension. I look forward to playing with it
when you are done!
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.)
I don't know how common they are either. Here is an example from my test
suite (debbugs.gnu.org being the culript):