packages with binaries

[Uday S Reddy]

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): 

Subject: 23.2.93; png not available
Message-ID: <83wrl76hkm.fsf at cs.bham.ac.uk>

...

Subject: Re: bug#8013: 23.2.93; png not available
Message-id: <83mxm2rcm8.fsf at gnu.org>
References: <83wrl76hkm.fsf at cs.bham.ac.uk> <831v3fsfdz.fsf at gnu.org>
	    <19797.7011.109000.33825 at gargle.gargle.HOWL> 
In-reply-to: <19797.7011.109000.33825 at gargle.gargle.HOWL>

Subject: bug#8013: closed (Re: bug#8013: 23.2.93; png not available)
Message-ID: <handler.8013.D8013.129742598817335.notifdone at debbugs.gnu.org>
References: <83mxm2rcm8.fsf at gnu.org> <83wrl76hkm.fsf at cs.bham.ac.uk>

The last message that closed the bug report has a bad References header,
making 83mxm... to be the parent of 83wrl...

> 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).

Yes, they are low-level.  That is the whole problem.  Low-level is where our
attention wanders.  That is where the bugs arise.  I wish it were
different...

Cheers,
Uday