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

[Eddie Kohler <kohler@aciri.org>]

> In sum, the current behavior for the nav-related
> variables is to follow *index listing order*.

Are you sure? I don't think so... For everything *except* thread sorting,
the $flip variable in compute_msg_pos (mhrcvars.pl) makes NEXT and PREV
correspond to the *normally-sorted* next or previous message. So in a date
listing, NEXT always corresponds to the chronologically next message, even
if REVERSE is on. This is the opposite of index listing order.

My patch brings TNEXT and TPREV in line with NEXT and PREV.

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

I don't think this is true either.

Currently, if TREVERSE is true, TNEXT behaves as follows:

    (1) If there is a chronologically next message in the current thread,
	jump to it.
    (2) Otherwise, jump to the chronologically PREVIOUS thread.

This seems inconsistent to me. And I don't think there's any way, using
layout resources, to get the following behavior, which I want:

    (1) If there is a chronologically next message in the current thread,
	jump to it.
    (2) Otherwise, jump to the chronologically NEXT thread.

But maybe I'm wrong?

> 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.

I understand your point. Rather than referring to intuition, let me explain
the principle that I want NEXT/PREV links to follow:

	 By default, NEXT/PREV links should behave independently of how the
	 indexes are sorted.

Reasons: 1. The index is not visible when looking at a message page. The
	    user should not have to remember how the index is arranged when
	    she clicks on a link.

	 2. The index helps users to locate messages. It is at least
	    partially independent from messages' sorting order. (For
	    example, Glimpse makes a great "index", but imposes no sorting
	    order.)

	 3. There are good reasons to reverse a listing (newest items
	    appear first on the page) or to keep the listing in normal
	    order (time flows downward). People should be able to
	    experiment with different index orders without changing the
	    meaning of the links on every message page.

	 4. Dates, in particular, have a clear ordering: chronological
	    order. If we agree that users should not have to remember how
	    the index is arranged to understand a link, then "Next By Date"
	    should mean "Next By Chronological Order". In fact, the code
	    currently works exactly this way.

	 5. Other orderings should follow the date ordering behavior lest
	    link behavior become inconsistent depending on index choice.

If people WANTED the NEXT/PREV/etc. links to behave differently depending
on the index sorting order, they could do so with layout resources (except
that the TNEXT/TPREV order is currently internally inconsistent, as I said
above).

This is a lot of text; sorry :)

love,
ed