Re: why isn't mutt threaded (logically)
> Well, applications aren't supposed to "multitask"; your OS already does all
This is a particular view which has some validity -- though I don't
agree, Alan Cox notwithstanding. Fortunately many other developers are
with me on that.
Addressing the OP:
For what it's worth, I think mutt would be better with some
parallelization in the IMAP code. However I don't think that would be
an easy thing to achieve with the current architecture and/or UI model,
and for now, if your priority is on quicker response, it's probably best
to choose the IMAP sync tool which sucks least for your purposes[1] and
use that. It's unfortunate, since part of IMAP's purpose is to relieve
you of local data store, but I don't see how to improve mutt's IMAP
performance without some significant design changes.
It might be possible to find a caching IMAP proxy that fits your bill.
This approach should work well, if you can find one that works right,
runs on your platform, doesn't require components you don't have/can't
get, etc. And it would be Alan Cox-compliant, so not as many people
would try to get you to change your problem definition.
[1] Most IMAP sync programs at this time meet a slightly different set
of requirements. The last time I needed to synchronize IMAP, I tried
about 9 existing packages before giving up and writing my own --
none of them met my needs, and couldn't be modified to do so more
easily than I could do it myself. And my program would be unsuitable
for your needs (and most everyone else's); merrily we roll along.
--
-D. "Neque porro quisquam est qui dolorem
dgc@xxxxxxxxxxxx ipsum quia dolor sit amet, consectetur,
NSIT->ENSS adipisci velit."
"Quia dolor sit." -- Cicero, De Finibus Bonorum et Malorum.