This analysis is incorrect. Chronology plays a secondary role when
it comes to threading. The linear listing order of a thread rarely
matches the actual chronological order of all messages in a thread.
Whoops! I understand the behavior of threading, but used the wrong word.
Sorry. My documentation patches got it right; for example, in
tnextbutton.html
<p>TNEXTBUTTON defines the value for the <code>$BUTTON(TNEXT)$</code>
resource variable when there is a next message by thread relative to the
current message. The next message by thread equals the next message in the
current thread or, if there is no such message, the first message in the
chronologically next thread.</p>
(2) Otherwise, jump to the chronologically NEXT thread.
This is a possible reasonable behavior, but can be considered
inconsistent with your logic. Since TNEXT within a thread can
go to an *older* message.
I think this is important, so let me try again.
I first used MHonArc via the GCC mailing list archives. I visit these
archives rarely, about once every two weeks. I like to catch up by picking
a message about two weeks in the past and reading forward by thread. My
goal is to maximize thread locality -- I want to read a thread all at once,
so that I understand the issues better -- and to move forward in time. It
is important to move forward in time because often a later thread
implicitly depends on the discussion in an earlier thread.
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.
Within a thread, TNEXT and TPREV work fine. However, at the end of a
thread, suddenly TNEXT does NOT do what I want: it takes me backwards in
time/dependency.
You may blame the GCC people for using TREVERSE. But I understand why they
used TREVERSE: it makes the index more convenient for frequent users. I do
not think TREVERSE should be deprecated. I think that TNEXT and TPREV
should be fixed: they should work consistently whether or not TREVERSE is
on.
However, since in a thread index,
date is secondary, I did no bother with it and requires extra overhead
computing tnext/tprev with questionable use.
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.
love,
ed
