On July 1, 2001 at 12:50, Eddie Kohler wrote:
I believe this behavior is reasonable and useful, and that MHonArc should
support it. But TNEXT and TPREV currently prevent me from doing this
without constantly going back to the thread index.
Behaviorial-wise, I aggree with you on how TNEXT and TPREV should behave
for TREVERSE.
You may want to check out the cache_msg_pos() function in patched
mhrcvars.pl. This function caches the results of compute_msg_pos(), which
may make things *faster* overall (particularly for LINKs). The extra
TNEXT/TPREV overhead is small anyway, and only takes effect at the
end/beginning of a thread when TREVERSE is on.
From a quick look at the code you sent, your cache attempt does not
appear to work since you reset it each time replace_li_var() is called
(losing what you cached). The cache structure must exist outside of
replace_li_var(), and be reset when a new archive is opened. I could
be wrong with this assessment since it is based on looking at the
patch data itself.
Side note: A primitive API exists to allow one to process multiple
archives in a single process if done in sequence. Hence, some
resources have to be handled via mhdysub.pl or handled properly to
not cross-pollute to another archive. Something easier to manage
if MHonArc is redone to escape its Perl 4 legacy.
I like the idea of a cache, but it can be quite expensive for large
archives where memory usage can be a problem. It is one of those
features that must be profiled to see if it is worth having. Note,
TNEXT/TPREV should only be expensive if TREVERSE is set since there
is already other potential hits one takes when using TREVERSE (mainly
when MULTIPG is active).
--ewh
P.S. Your MUA dropped the subject text in your reply.
