Valdis.Kletnieks@vt.edu writes:
On Sat, 06 Apr 2013 16:38:22 -0700, Lyndon Nerenberg said:
In fact, the whole concept of 'threads' is something I would like to keep
outside of the base toolset. The reason being there is no single definition
of
what a 'thread' is, and even when you can come up with a definition, it's
almost always context sensitive. I have never found an MUA that can come
even
close to expressing the sort of detail I want when dealing with threads.
exmh apparently has at least some thread support. However, I don't use
it because it has completely horrendous perfornamce characteristics, since
the folder I want to use it the most has thousands of messages and hundres
more each day. As a result, it has to read all the messages of interest so
it can find all the In-Reply-To and References: headers.
MH-E limits threading to the current view and doesn't thread the folder
by default if the view is larger than a configurable amount. Threading
the last couple of hundred of messages is sufficient and fast.
gnus is fast too, but it limits its threading to the current view as
well.
This begs the question as to what the "current view" in MH is.
You'd really want to have a cheap incremental method of adding incoming
messages to a thread database, similar to how rcvstore currently updates
the unseen sequence.
Or a simple per-folder dot file. For example, in MH-E, a search index
called .mhe_index serves as a mini-database for the search result.
--
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers