I'll second this, but...

A braindump of sorts follows... useful or not, I can't say.  Implementation will be rather less straightforward than a simple read of the original request might suggest, unfortunately, thus the braindump.

Reading the filing triggered my memory of the multi-part single message thing, (x/y) vs (a/y) vs (b/y), and the duplicate headers issue it caused.  That one was solved by simply omitting the numerator (x), so they all became (/y) and the duplicate header issue disappeared.

The same issue would likely occur here, complicated by the fact that for performance reasons, if I've understood various remarks correctly, pan's message threading isn't entirely dynamic -- the thread tree is created as a initially and saved to disk at group change or pan quit, to be retrieved from disk at pan start (or maybe group entry?) thus avoiding the re-thread operation.  Additional posts to existing threads are plugged into the existing tree at the appropriate location as they come in.

If we start dynamically and on-demand pseudo-threading (and re-rethreading with the updated call it [x/y] (suggest we standardize on that so as NOT to confuse it with the existing (/y)) stats as necessary) post groups as suggested above, that's going to negatively and directly affect performance.  I don't believe it'd be worth it.

Thus, what we are left with is the same thread-once-and-add, replace [x/y] with [/y] at original thread, as we are now using for (/y).  We get the total count y (if supplied in the original subject, we may have to stay unthreaded if not, since there'd be no way to determine whether y is complete or not), but can't do the proposed [x/y] without either negative performance effects or triggering the same duplicate bug but in a different way.

Alternatively, we could just (pseudo)thread, and leave the [x/y] display entirely unmodified from the original subject line.  That would still be an improvement, and would be less complicated.

In either case, without an additional out-of-band (subject line in this case) data channel (think another icon or column), there's still be no way for the user to tell if the post group/series was entirely complete or not, without having to actually expand the thread and count the posts, because x/ wouldn't be unchanging at original pan threading and subject line database entry.  Without that, the feature loses much of its benefit, unfortunately.

OK, so now we are debating what form that out-of-band data channel could take and whether it'd be worth it.  If we simply stick to a binary complete/not-complete representation in the existing column, we could adopt the convention that a collapsed binary pseudo-thread's icon represented the state of the thread as a whole, /not/ the individual multi-part single message, simply overloading the meaning of the red/green puzzle-pieces in that special case (collapsed binary thread).  No more header pane space would be taken, and no new icon resources required.  A variation would be coming up with a pair of additional icons, thus avoiding the meaning overloading (more intuitive for the user, Charles, this sounds like the solution you'd prefer =8^), but we have the problem of actually coming up with additional icons both distinctive enough to visually show the difference, and intuitively suggestive of their purpose.

The other out-of-subject-line-band data channel would be yet another column, in which case we could go with a conventional x/y notation and be done with it.  The negative of course is that it's yet another column, on header pane display already populated with enough columns to make it next to impossible to display them all.  Of course, pan already has a columns to display preferences tab, so folks who chose to could leave it hidden and have basically the same info they have now (plus the pseudothreading, of course), but it's still yet another column /choice/ and choosing it would almost certainly mean abbreviating or excluding another column to make room.

It's probably obvious, but I favor using the existing state column, with additional icons or overloading the existing puzzle pieces, doesn't make much difference to me.

---

Another factor to consider is that these groups/series aren't always identically typed files, either.  Probably the most common additional files are the par2 files, but there's sfv's, txt's, and others, on occasion, all labeled as part of the same [x/y] sequence.  These would all be pseudo-threaded together.  pan will have to pseudo-thread off the [x/y] numbers where present, which could leave the displayed thread "root" with something other than the most informative subject line, when the thread is collapsed.

Finally, there's the issue of getting the pseudo-threading correct, when the [x/y] might be anywhere in the subject line or maybe even omitted (if we even try in that case), or where the meaning of [x/y] and (x/y) are reversed in the original.  pan seems pretty good at getting it right with multi-part single messages now, but would it continue to be as reliable trying to both single-entry that and thread "post groups" as well?

Just wanted to comment, I feel this would be a awesome feature.

Adding a me too onto this request.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pan/issues/14.