Re: packages with binaries

Stephen J. Turnbull writes: Ok, it looks like we have agreement on that issue :-) Quoting from the current VM Manual, Sec. 10.1: "Unlike in previous versions of VM, threading is not a form of sorting. You can sort threads by the usual sort keys and the sort order will apply to at least the root messages of threads. Sorting threads by subject, for instance, can be a quick way to find threads with similar subject lines. Sorting them by date would sort them chronologically according to when the threads were initiated. Sorting them by activity is a variant of the chronological order where the dates of latest activity are given prominence instead of the dates of the initial messages." How the threads affect the sort order is of course handled in the sorting function. There are some mathematical compositions for sort-orders, such as the lexicographic combination etc. Once you plug in the right sort-order into the sorting function, it will produce threaded sort combined with various other sort keys. But building and maintaining the thread-tree is entirely separate to sorting. That is done in the vm-thread.el module. I am not sure that the data structures are entirely similar, but the principles certainly are. When I first looked at VM's code, it was quite impenetrable. So, I went around googling, found Jamie's page, understood what the issues were, and then came back and read Kyle's code. It had pretty much the same ideas. The details differ. Jamie is only concerned with building the thread tree. He doesn't care to maintain it. On the other hand, in VM, we maintain it and do insertions/deletions as messages arrive or leave. For instance, Jamie says, if there is an empty container, you can "nuke it". We can't. A message that needs to go into the empty container might arrive at any time. Instead, what we do is to calculate the visible lineage of each message separately (called "thread-list") and cache it. If a new message arrives to fill a hole, then the cached info is erased and recalculated. (There is a section on threading in the "VM Internals" chapter of the VM Manual. Please see that for full details.) One of the reasons I took pains to fix the problems with the threading code is that I would like to extend it as per the modern needs: merge broken threads, detach subthreads that go off-topic, and worry about identifying duplicate copies that come with different message id's (thanks to our Mailman, gmane and gnu.org friends). I don't know if you will be able to do all these things if you use Jamie's build-and-discard approach to the threads database. I do buy the fact that we have a lot of cycles available these days and can afford to be lazy in coding. Oh, if I do understand why it proved to be so hard, it will probably go into a journal or perhaps it will turn into a bigger project! Cheers, Uday _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta