OT - the OT tag and the Re bug.

If I understand what you've written, I disagree: it is clearly a bug and
not "understandable". As you point out, messages w/in a thread should be
in an order consistent with thread ordering. But the relative ordering of
threads themselves is - obviously - independent of threading. One should
be able to order threads however one wants (subject, date, etc.).

Suppose you start a thread called
OT: bugs in aviation.
The response to the first message comes from a "good" reader, and has
the subject
OT: bugs in aviation.
The response to that response is from a "bad" reader, and has the subject
OT: bugs in aviation.
Somebody else, with a "bad" reader, responds to the first message. His
subject line is
bugs in aviation.
Somebody with a "good" reader replies to that message. The subject is
bugs in aviation.
Someone with a good reader replies to the first message, and overrules
the subject line. His subject line is:
GPS bugs (was OT: bugs in aviation)
Someone with a good reader replies to this message. The subject is:
GPS bugs (was OT: bugs in aviation)
Someone with a very bad reader replies to the "overrule" message. The
subject line is:
bugs in aviation)
(everything in front of the colon was replaced with "re")
etc.

On Monday the first of Augtober, I read the first message in the thread.
By Tuesday, the rest of the messages have come in.
On Wednesday, I sign on again. I want to see a list of THREADS,
alphabetized by SUBJECT LINE. (I don't want to see a list of all
messages, just all threads, and the number of messages in each thread)

So, how should these messages be sorted?

Jose
--
There are two kinds of people in the world. Those that just want to
know what button to push, and those that want to know what happens when
they push the button.
for Email, make the obvious change in the address.

On Tue, 29 May 2007 21:32:30 -0400, Jose wrote:

On Monday the first of Augtober, I read the first message in the thread.
By Tuesday, the rest of the messages have come in. On Wednesday, I sign on
again. I want to see a list of THREADS, alphabetized by SUBJECT LINE. (I
don't want to see a list of all messages, just all threads, and the number
of messages in each thread)

So, how should these messages be sorted?

If your reader is like mine, it lists threads (as opposed to messages) by
"collapsing" the listing. So you'll see the "top" message for each tree
of replies.

These top messages will be sorted by subject.

No message that is a reply to any other [unread] message will be visible
in this listing because it is collapsed. If you "open" a thread, those
replies will become visible (and nested or somehow flagged as being
internal to the given thread's tree).

Hmm. You may see the replies to the first [read] message separately. The
reader knows that they're connected, but it doesn't have any way to
graphically display this (because read messages are invisible). That is,
there's no way to display the fact that two replies to the same [read]
message are in the same thread because there's no visible construct under
which both messages can be placed.

Is that the problem you're describing?

If so, all you need is a reader that actually displays thread tops
rather than the top message in the thread.

My reader (pan) doesn't do this. I'd never noticed this before. But if
I want to force a thread to maintain its tree structure over time, I do
need to change the filtering to display read messages too.

Trying this, I don't particularly like it even though I still have
"next unread" (and now I know why that exists {8^) and it clearly
indicates which are read, unread, and new. It just uses too much "space"
in the expanded view. But this is how one would need to see an entire
thread.

I think displaying a separate artifact on the list for "thread top" would
work too, though.

- Andrew

On Wed, 30 May 2007 10:12:19 -0400, Andrew Gideon wrote:

Trying this, I don't particularly like it even though I still have "next
unread" (and now I know why that exists {8^) and it clearly indicates
which are read, unread, and new. It just uses too much "space" in the
expanded view. But this is how one would need to see an entire thread.

Umm...I've tried using this for a bit, and now I'm not so sure. I rather
like being "in a thread" rather than reading messages. And pan offers
keyboard shortcuts for expand/collapse thread etc. which are suddenly
useful.

Only threads with unread messages are appearing. So my message list is
actually looking less cluttered than before, even though when I expand a
thread I see all the unread messages listed.

Let's see what happens when I come upon some really large threads (which
is bound to happen here sooner or later {8^).

- Andrew

If your reader is like mine, it lists threads (as opposed to messages) by
"collapsing" the listing. So you'll see the "top" message for each tree
of replies.

Exactly.

Hmm. You may see the replies to the first [read] message separately.

Exactly. So now I have three trees under:

bugs in...
GPS bugs...
OT...

where ideally there'd just be one listing, under
OT...
where all the other OT posts, threads, or trees would be sorted

That is,
there's no way to display the fact that two replies to the same [read]
message are in the same thread because there's no visible construct under
which both messages can be placed.

Is that the problem you're describing?

Yes, that is one aspect of it.

If so, all you need is a reader that actually displays thread tops
rather than the top message in the thread.

What if the thread top is six months old?

My reader (pan) doesn't do this. I'd never noticed this before.

Go back and see if, for an OT thread with the colon (for example, the
one about Electric cars), you see separate trees, one that starts with
OT and another that starts with Electric.

Trying [show read messages too], I don't particularly like it

Neither do I. It's clumsier than simply putting up with the defeat of
the OT prepend.

Umm...I've tried using this [same thing] for a bit, and now I'm not so sure.
I rather like being "in a thread" rather than reading messages.

Yes, that part is nice. But sorting trees by subject line is
problematic, and that's how I'd like to sort them.

Jose
--
There are two kinds of people in the world. Those that just want to
know what button to push, and those that want to know what happens when
they push the button.
for Email, make the obvious change in the address.

Recently, Jose posted:

[...] But sorting trees by subject line is
problematic, and that's how I'd like to sort them.

OE sorts trees by subject line, but if the subject line changes, you get a
new tree root if read files are hidden.

I really don't see a way to resolve all of the possible ways that readers
deal with thread headers into a universally consistent practice. Someone
will always come up with an app that does something wacky.

Neil

OE sorts trees by subject line, but if the subject line changes, you get a
new tree root if read files are hidden.

Right. This is what happens with Netscape too.

I really don't see a way to resolve all of the possible ways that readers
deal with thread headers into a universally consistent practice. Someone
will always come up with an app that does something wacky.

Right. But if posters avoid following a prepend with a colon, this
issue won't be an issue.

Jose
--
There are two kinds of people in the world. Those that just want to
know what button to push, and those that want to know what happens when
they push the button.
for Email, make the obvious change in the address.

Recently, Jose posted:

I really don't see a way to resolve all of the possible ways that
readers deal with thread headers into a universally consistent
practice. Someone will always come up with an app that does
something wacky.

Right. But if posters avoid following a prepend with a colon, this
issue won't be an issue.

What of those readers that truncate long lines or as in your app's case
oddly truncate subject lines that have mulitple "OT:" in them? I'd think
that the multiple tree roots would be the more desirable consequence.

Neil

What of those readers that truncate long lines or as in your app's case
oddly truncate subject lines that have mulitple "OT:" in them? I'd think
that the multiple tree roots would be the more desirable consequence.

Those wouldn't be issues either.

Truncating: Avoiding the colon doesn't lengthen the line (except for the
first re. It merely keeps the original OT in the subject line. It
ensures that "OT" is not treated special.

My app doesn't "oddly trucnate subject lines". Other apps do when they
reply. Then =everybody's= app (including mine) gets multple subject
lines, defeating the point of a prepend. Check out prior threads which
started with OT and a colon, or watch the "OT: Eagle, not waddling"
thread develop and you'll see a new subject line appear without the OT
as soon as somebody replies to it with a "bad" reader.

I don't understand when multple tree roots would be better.

Jose
--
There are two kinds of people in the world. Those that just want to
know what button to push, and those that want to know what happens when
they push the button.
for Email, make the obvious change in the address.