For the purposes of demonstrating the problem, the same relatively small set of posts were selected from comp.sys.acorn.apps and displayed in a seperate box in both Pluto (on RISC OS) and Gemini 2.29l (on Windows). Since this page is primarily describing the problem with Gemini, I'll look at that first.
The problem is that a threaded group seems to be incompatible with my preferred approach to usenet and mailing lists - which is to delete posts as I read them, keeping only those I might follow-up myself later, after reading all of my messages; when deleting a post, Gemini doesn't simply display the next logical post for reading. Instead, it sometimes skips posts, sometimes jumping to the next thread and sometimes back to the start (presumably rolling around from the end to the beginning) - which means that at any given point, the message displayed might actually be one that's already been read, but retained for possible reply, even if there are still messages yet to be read. Additionally, as you move from one message to another, the threaded list of messages can collapse and/or (partially) re-expand.
From a user's perspective, this seems totally random, though there almost certainly is a pattern to it - the collapsing/re-expanding thread list makes it difficult to see such a pattern (assuming it would be possible for a user to ascertain it by looking at the list).
I've modified my Gemini settings to display everything in a single window in order to simplify obtaining these screenshots, and I've trimmed the resulting images to show just the threaded display and the top part of the messages (so it's clear which message is being displayed).
This is the complete thread with no messages opened.
With the first message opened, the thread display is the same; the
only difference being that the opened message is highlighted.
After pressing ctrl-D to delete the message and open the next,
this is the display.
Note that the threaded list is still okay, but I imagine that's because the message that was deleted was one in a thread on its own.
After pressing ctrl-D to delete the message and open the next,
this is the display.
This time, the thread has partially collapsed, and no message is highlighted in blue - but there is an outline highlight around the first message in the next thread. The message being displayed, however, is the one you'd expect from the original list of messages; this is the third message that's been displayed, and it's the third message in the original list (and the first item in the current list).
I can see (now that I'm looking at this in detail in order to report the problem) that the reason for the collapsing of the threads is to restructure them to keep them clean and logical - the post I've just deleted was the parent to the thread it was in; deleting it has caused Gemini to restructure the subthreads of that as individual threads in their own right.
After pressing ctrl-D to delete the message and open the next,
this is the display.
This time the threaded list doesn't appear to have changed significantly other than the first message in the list changing, (because the message that was the first in the list has now been deleted) - the displayed message is now the first in the list - along with which message is outlined. (And, again, the displayed message is the next logical one as per the original list). This message, I'm going to 'keep for later' rather than delete.
So, after moving to the next message without deleting the last, the
screen looks like this.
Another change in the thread display has occurred - and this time, it looks reasonable; the highlighted message is the one being viewed, and that subthread is open in order for that to happen.
After pressing ctrl-D to delete the message and open the next,
this is the display.
Again, this looks reasonable. The first line shows the message that I kept, and there are no messages threading directly off of that one. The next line shows the (opened) subthread I'm on, with the message highlighted being the one I'm reading.
But after deleting that message and opening the next, this is the
display:
The message displayed is the right one: it was the one that followed the one above. It's not highlighted in any way (nothing is in the part of the thread display that's visible) but it's showing as unread because it's now opened. However, its location in the tree has moved - it's now below two unopened subthreads. This probably explains what happens next.
Once again, a Ctrl-D to delete the item displayed and open the
next, and the result is this.
I'm now in the next thread - presumably the result of the previous thread's structure being changed as I deleted articles - even though there are still items unread in the previous thread.
Similar things will continue to happen as I continue to read the posts as I have been doing, so I'm going to skip forward a bit now.
As is fairly plain to see, the displayed item is the last one in the now fully collapsed list - which means that (as with the previous thread) some items have been skipped over. I'm going to keep this post, and move to the next without deleting.
Upon doing so, this is what I see.
This time, the only change to the threaded display is that the final subthread is expanded, with the displayed item highlighted.
And pressing the usual ctrl-d to delete that and display the next
shows me this.
What I'm seeing is the first of those two posts I've kept out of what I've read so far. (Which means I have to move on without deleting it - again).
Moving on from that last (re)displayed item, now gives me this.
I'm now seeing one of my previously unread items, which is highlighted - and that subthread expended.
Deleting that and displaying the next gives this.
A collapse of the subthread, and nothing highlighted - but the item in question is showing as unread (the third one down). Note that this means that subthread has shifted position - above, it was the second one down.
A delete and display next, gives this.
As with the image immediately above, the item being displayed is the third line on the list - and because of the previously noted move to being in that position is probably the reason that the next item displayed after deleting this is from the next thread.
Displaying any more from this sequence is now pointless - everything that happens is covered by those above.
It's fairly clear that the root of this problem is that Gemini is restructuring the threads as the messages are deleted, in order to keep them logical and 'clean' - but that means that the position within the list of the message being displayed is changing, and that in turn means the next message to be displayed will also change; the result is that entire subthreads are, in effect, skipped over as the message (and its contaning subthread) are pushed further down the list. (So it's not as random as it might at first seem, which I suspected).
The fact that the threaded display is collapsing and re-expanding is, I imagine, a side effect of the restructuring - and the fact that the displayed message isn't always highlighted is probably an effect, in turn, of that.
When Pluto (on RISC OS) is used in a similar way, it does not attempt to restructure the threads as they are read. It simply removes the message that has been deleted from the list.
As with describing the problem in Gemini, screenshots will aid greatly with explaining this.
Pluto doesn't expand every thread in the group, only the thread currently
open, so this combination of four screenshots shows that the same messages
are being used, with the same threading.
Note that I normally use 'Threads-status' as my sorting method in Pluto, but I used 'Threads-subject' to ensure it presented the messages in the same order as Gemini in the first instance. Note also that in these images, I don't include any element of the message itself - only the threaded list. This is because it's not necessary in order to explain this, mainly because of the way Pluto works.
What this group of four images show, amongst other things, is that the threaded messages (when the thread is expanded) begins on the line below the thread title. I'll mention this again below, because it's relevant to how Gemini could handle threads.
I open the first message, as originally in Gemini.
The thread is expanded (all one message of it!) and the message is highlighted.
Upon deleting that message and opening the next, the threaded display looks
like this.
Again, the displayed message - the first one in the now first thread - is highlighted, and the thread structure is just as displayed above, in image 00b.
Deleting that message and displaying the next gives this.
Once again, the displayed message is the one which is highlighted, and it's again the first in the thread, and the tree remains expanded; I can see what's still to be read, etc.
The only slight problem with this is that the details for that message, starting with the icon, have all moved left slightly in the display, resulting in the tree for the other subthreads coming off of this message. In other words the threading seems to indicate that this is now the parent message in the thread, which it isn't - but that really is a minor issue.
Deleting that message and displaying the next.
Everything written for the image above applies here.
It continues to work this way as I continue to delete messages and display the next; the threads aren't restructured, which means that the order of the messages (in their subthreads) doesn't change, which means there is no skipping of unread messages - even when retaining a message, for which I'm going to skip forward a bit.
Having deleted a number of articles, I've now reached one I'm going to
keep in order to reply to later.
At this stage, because I've been deleting as I go, it's obviously the first item listed.
Moving onto the next message without deleting it gives this.
The retained message is still first, and the second message is now highlighted - that being the one displayed. There is still the problem of the tree display becoming slightly odd, but as I've already said - it's a very minor issue.
Again, continuing to read in this way results in entirely consistent behaviour from Pluto, even when it reaches the end of the thread and moves to the next.
And that's the point I've reached with this image.
The thread with the unread message is collapsed, and the thread now being read opened, with the displayed message the one highlighted.
I'd ask that Gemini be modified to work in a similar manner to Pluto - with an expanded thread having the first line as a title, and the thread itself displayed below that, and the displayed message highlighted. When that message is deleted, rather than restructure the thread (only do this if the user actively collapses the thread and reopens it), simply remove that item from the list, shifting everything below it up by one line.
Similarly, truncated/seperated subthreads should be grouped under the same thread heading if the subject matter is the same, but there are no mutual parents.
Where Gemini could improve on Pluto is in dealing with the minor issue mentioned above - perhaps start the tree for each thread with the thread title, rather than the first listed message? This would mean that orphaned subthreads of the same original thread, rather than seeming to follow from the first message, follow from the title itself.
However, Pluto's method is just 'what I'm used to' which may not matter in the long run; if Gemini's problem with reading news and lists this way can be resolved using a different approach then that's fine - if it works sensibly, then I'll get accustomed to that.