1. is the sent folder explicitly listed in the sources for the vfolder
in question.

2. they're just still updating.  The 'waiting long enough and it fixes
it', is kind of a hint here, you think?  In some cases they update in
another thread which the mailer doesn't know about.

1. No, but the virtual folder is set to use all local folders, which
would presumably include Sent.

2. Well, yeah.  But it's still weird that it silently appears as
empty, without any sign that it's working, in the status-bar for
instance.  I think the lack of notification should probably be
considered a bug, albeit not the worst imagineable.  Also, at one
point at least, I noticed that the folder in question was empty, but
the CPU didn't seem to be working particularly hard.  So I'm not 100%
sure that this problem always correct itself, but I'll keep an eye out
and add a bug report here if I can verify the problem.

A final thought about virtual folders:  it's too bad that virtual
folders take so long to start up, even when nothing has changed from
the last time.  It might be useful to cache previous views of virtual
folders, so that restarting is faster when most of the folders are
unchanged.

I managed to fix the problem, with the following hack:  I have a
VFolder called Everything, which has a hacked-up filter condition
(accept if status is or is not replied to) so that it accepts all
messages, and takes them from all local folders.  I have another
VFolder, called All, which takes everyhting from the specific folders
Everything and Sent.  Then I build by other vfolders to filter off of All.

Once I do all that, then the messages from Sent do in fact appear as
they should.  But it's a painful little hack that normal users
shouldn't be expected to come up with.

You can probably just add 'sent' to the source of the other vfolders.

Sent isn't normally added because people dont normally want to see
stuff from sent in their vfolders.

I've got yet more VFolder flakiness.

First, something simple:  the up-down buttons in the virtual folder
editor don't really work.  If you select a file, and click up, it
moves up one in the list.  But press up again, and the wrong folder
moves up by one.  It's actually worse than that, but it's hard to
quantify exactly how it's broken.  Also, the order does not seem to be
reflected in the VFolders display, so it's not clear why the order is
there to be edited anyway.

Now something worse:  I have the setup I outlined above, that is, I've
got two virtual folders that others are built on.  The "All Received"
has everything except the Sent folder, and "All" has everything in All
Received plus everything in Sent.  It was all working fine, but then I
added a "saved search".  When I turned it on in any folder based on
"All", everything except the messages in "Sent" disappeared.  What's
weird about this is that clearing the search didn't fix the problem.  

A possible cause is that, in the same session, I changed the name of
one of the virtual folders.  In particular, "All Received" used to be
named "Everything".  It occured to me that maybe "All" was pointing to
the wrong folder, and the saved search just made it notice the
mistake.  But I checked "All", and it correctly points to the "All
Received" folder where it used to point to everything.  I deleted "All
Received" from "All" and then re-added it, to no effect.

Finally, some further weirdness on the "empty folder" problem.  When I
start up evolution on an empty folder, top indicates that evoution
isn't doing any computation, and the hard-disk isn't whirring, so it
seems like evolution isn't doing any work.  Also, it sits there for a
fairly long time without the messages appearing --- on the order of a
few minutes, and this is on a 766 MhZ P-III, with plenty of memory and
nothing else to slow it down.  The VFolders based on "All" are the
ones showing no contents, but interestingly "All" itself displays
messages.  Furthermore, after this restart, "All" has the same
contents of "All Received", even though it's supposed to in addition
have all messages in Sent.  After editing the virtual folder, removing
Sent and then adding it back, All has the extra messages its supposed to.

I'm not sure how helpful this long tale of woe is.  The basic message
is: virtual folders are still rather flaky.  Maybe this is because I
play with virtual folders built out of virtual folders, which most
other people don't do. 

(by the way, it's been about 10-15 minutes now, and the virtual
folders have still not started displaying messages.)

Yet another problem.  I only add it because it suggests that this
isn't just a problem with Vfolders within Vfolders.  Basically, I have
a "recent" vfolder, that has all messages from Sent and Inbox from the
last week.  When I startup, it has only the contents of Inbox.  When I
go to the Vfolder editor, open up the configuration for "recent", and
then close it,   then suddenly the contents of Sent appear as they
should. 

This is replicable:  if I restart evolution, "recent" will be missing
the members of Sent.  If I edit the definition, change nothing, and
click "Ok", they come back.

Aha!  I have learned something new about the problem.

Turns out, the order in which VFolder descriptions appear in the list
of vfolders matters a great deal.  Evolution somehow ended up in a
state where the vfolder "All" appeared after the vfolders that use All
as input.  I think vfolders content is computed in linear order.  So,
assume vfolder B is based on vfolder All.  B appears first in the
order, so the contents of B are computed first.  At that point,
there's nothing  in All, so B appears empty.  Then, All's contents are
computed, and All is filled up.  Then, when you cause it to recompute
the contents of B (by editing the definition), then B now is built off
of All's actual contents, and gets all filled up.

If my diagnosis is correct, then the solution is to enforce the
following invariant on the code:  if folder A is built off of folder
B, then folder B must appear before A in the folder order.  

I suspect that it got into this state through a renaming:  The folder
named All previously had a different name.  The renaming probably
moved it to the bottom of the list.  So at the very least the renaming
operation should not change the order.  And probably, the order has to
be organized using a topological sort on the dependency relationship.
 (If you don't know how to do a topological sort, look it up in Cormen
Liecerson and Rivest, or your favorite algorithms text.)

Note, this does not quite explain why similar behavior occurs with
vfolders that include Sent. 

Vfolders are built in order they're defined, however as sub-folders
are changed (i.e. new messages appear), new messages are added, etc.

Does anyone at Ximian actually think this is a bug?

I've submitted pages of detailed analysis on this bug, and at this
point I've given what I think is a decent roadmap to fixing it.  But I
haven't gotten any real feedback.  Nothing of the form:  "Yes, this is
a bug, and we'll fix it."  I'd be happy with, "Yes, this is a bug, but
go fix it yourself.", or even "I'm not convinced it's a bug."  

But it's quite frustrating to feel like I'm tossing detailed bug
reports into the void.

I assumed from the version number that youi're using a recent version,
however these symptoms sound like you're using an old version.

Please try version 1.0 and see if it still happens.

I have always been using the latest available version from Red-Carpet.
 THe problem persists in 1.0.

I dunno if this is related to the above problems, but it is similar.

I am using Evo HEAD cvs (maybe that is bad).

1. create a vfolder (say: mail received in the last day) 
2. name the vfolder 'Today's Mail'
3. Attempt to use vfolders: 'Today's Mail' shows the contents of
'Unmatched' and 'Unmatched' shows the contents of 'Today's Mail'.

4. Delete the 'Today's Mail' folder.
5. 'Unmatched' now works again.

virtual folders of virtual folders got a lot better, but a complete
fix depends on a rewrite.

i'm talking 1.2 code here, 1.0 is dead.