Re: patch: improved TSLICE, thread navigation, ...

[Earl Hood <ehood@hydra.acs.uci.edu>]

On June 24, 2001 at 21:09, Eddie Kohler wrote:

> I've made several changes to the source that other people may find useful.
> The source patches are ready; I haven't updated the documentation yet, but
> I'm happy to if the patches are accepted. I'm not sure if there is some
> protocol for submitting things like this, so here they are.

Thanks for the patch submission.  When time permits, I'll do a review
of what you got and apply the changes.  Of course, you do have patches
for the documentation? :-)

Note, quick comments below on changes:

>   - Navigations TNEXT and TPREV now work chronologically, even if TREVERSE
>     is on. Previously, if TREVERSE was on, TNEXT would move chronologically
>     forward within a thread, but chronologically backwards between threads.
>     The new behavior is more like NEXT and PREV and more intuitively
>     sensible.

I'll have to rethink this issue again.  God only knows how many times
I thought about this.  In sum, the current behavior for the nav-related
variables is to follow *index listing order*.  I believe this is documentated.
I leaned towards being consistent in this manner even if it contradicts
some intuition.  I.e.  It is trickier to rely on intuition since it can
vary among people.

Note, I have advised against the using of TREVERSE since it also
contradicts some users intuition on what it should do when thread index
pages are generated.

BTW, technically, the current behavior can be "hidden" by use of
layout resources.  The issue really only deals with default behavior.

> - Add SUBJECTNOTHREADRXP resource. This regular expression prevents
>   messages from being threaded by subject. I set it to "^No Subject$|^$",
>   so that messages without a subject are never marked as "Possible
>   follow-up(s)" to one another. Default regexp matches no messages.

I'd prefer to call this SUBJECTTHREADSEXCRXP.  I'm also interested
on how it impacts performance.  BTW, your summary is not completely
accurate since SUBJECTTHREADS exists for disabling any subject based
detection.  For performance, it may be more efficient to just hardcode
the exclusion of "No Subject" since I do not know if there are any
other real cases to support anything else.

> - Change AUTHSORT and SUBSORT so they sort messages by reverse
>   chronological order within author/subject groupings, but the groupings
>   remain in alphabetical order. This seems more generally useful. (But this
>   behavior could be controlled through some resource.)

This should be removed or resource controled.  Existing default behaviors
should not be changed unless there is a good reason.  Since there is
an existing user base, there may be some that have unknowning rely on
the existing default behavior, and if changed, the appearance of their
archives are quietly changed.  Probably have a resource that controls
the chronological order of messages listed in a group.  I've considered
this a long time ago, but never got around to it.  Should complicate
the sorting code a little.

BTW, this would affect the "intuitiveness" of the NEXT/PREV links.
If you consider all possible combinations on how messages can be
ordered on index pages, you will start to understand the problem on
relying on "intuition".  Luckily, with page layout resources, you
can "force" the generated output to follow whatever you desire.

> What do people think?

In general, I like the changes since many have been requested
features.  I'll not be able to really do anything with your patches
until probably next weekend.  I'd also like to make sure the docs are
updated with any changes made.

I'm actually impressed that someone else, besides myself, went through
the tedious effort of adding new resources to MHonArc.  The Perl 4 legacy
of the code makes some additions an excercise in discipline and not
a tribute to good design.  Adding a resource at least requires a change
in 4 source files along with whatever source files are to take advantage
of the resource.

--ewh