StephanB posted on Sat, 18 Feb 2012 17:14:04 +0000 as excerpted: > can anyone tell me how to configure pan to show multipart messages in a > threaded view?
It would of course help if you mentioned what version of pan, since the way pan handles that has changed over the years... I tried to get it from your headers, but if I'm reading them right, you did use gmane for posting, but the web interface instead of the news interface, so firefox, not pan, so of course no pan version header in your post. But, I'll assume it's something close to recent, say version 0.130 or newer... The first problem we have is that in the news context, there's at least three different message variants that can be described as "multi-part", but the "parts" being described are vastly different, in terms of the raw message and pan's handling thereof. Given that you didn't include enough context with your question to know for sure which of the three you meant, I guess I describe them all and you can pick the one that matches what you intended. 1) The closest match technically is to the multipart MIMEType. MIME is the standard setup to allow messages to contain multiple parts and to properly ID and demark each part as text message, attachment, HTML, etc. A simple MIME-compliant message contains only one part, either the message text, or possibly, an attachment, say an image or sound file. A message with multiple such parts will specify in the overall message MIMEType header a type of multipart/mixed, or some such, and each individual part will have its own MIME headers describing what it is and its relationship to the message in general, among other things. But while this is the closest technical terminology match, such "multipart" messages generally appear as a single raw article as stored and as transmitted on-the-wire, and with certain exceptions (message/ digest, for instance), the concept of threading really doesn't make sense here at all, so despite it being the most accurate match for "multipart", it's unlikely that's what you meant. 2) Then there's message segments. When a single message gets quite long, especially if it has binary attachments which tend to make it MUCH longer than simple text messages tend to be, most clients have a maximum size setting, and will automatically split the message into separate segments, each containing a part of the message, to be recombined at the other end. Over the wire, each of these individual segments appears as its own separate article, but it's really just a single message that happened to be split into multiple individual raw articles because it exceeded whatever maximum single-segment size had been configured in the sending client. At the receiving end, most clients can detect such messages and recombined them, often automatically, for display and/or saving off of the attachments. In the message list, some clients will display all the parts "threaded" as if they're replies to the first part, but really, they're all part of the same message, and regardless of how they're displayed in the message list, as a single message, as separate messages all at the same level, or "pseudo-threaded" with all parts but the first appearing to be replies to the first part, a good client will automatically recombine them (at least as long as all individual segments are there, if some are missing a good client will display that somehow and not combine them automatically, but will still let the user force a combination of all that's there, even tho it'll obviously be corrupt) for display of the message body, because regardless of how many segments it was actually delivered in, it was originally a single message and the display at the recipient should show it as a single message as well. This is I'd guess most likely what you meant. But pan normally handles this /entirely/ transparently. Since the message was composed as a single message before being split as it was sent, pan will display only a single line for it. If parts/segments are missing, pan will note that with the incomplete puzzle piece icon, and the number of total and available segments will be shown in the subject line. If all parts/ segments are there, it'll be the complete puzzle icon and IIRC pan will remove the parts notation from the subject line entirely. (FWIW, I haven't done binary groups in years, so don't remember for sure whether it shows say 23/23 for a complete message or removes that entirely, I think the latter.) Since pan lists this as only a single message, there's no way it can be displayed as threaded. FWIW, this allows pan to be a bit more memory efficient and therefore to scale a bit better, since it can treat the whole message as a single object, instead of a bunch of objects, tracking some information only once instead of 3 or 50 or 100 or whatever times, depending on how many individual segments the message was split up into. Long ago, pan did what you describe, displaying the individual segments threaded. But back then, pan would crash or simply stop responding at maybe a couple hundred thousand articles/segments in a group, whereas with that memory management improvement among others, it now handles several million messages in a group. But even still, on 32-bit systems especially, if you get in a big group on a good server and try to download the tens of millions of overviews available, pan will reach the maximum 2G or 4G available memory and crash, well before it gets all the available articles listed. It can even still happen on 64-bit systems with 8 gigs of RAM (I don't know that it has been tested with 16 gig plus), but it takes more to do it, say 10 or 50 million instead of perhaps 5 million. (Numbers picked out of the air for illustration of scale, but it's definitely in the millions now, while it used to be well under a million.) 3) In groups with super-large attachments, say CD/DVD image groups, it's often common for a poster to pre-split the file into say 50 or 100 MB pieces, then post each of them as a single message, which in turn gets automatically split up by the client into segments/parts as in #2. At the receiving end, each auto-split gets auto-recombined into a single message again as in #2, but there are several of them that each contain a file attachment that's a split-part of the original very large file. The receiver will save off these individual files, then when all of them are available, he can recombine them using either a copy of the same program used to split them originally, or something like the Unix cat (conCATenate) command (generally with the output redirected to a file, thus recreating a copy of the original file) or the MSDOS copy command. Pan will treat these as individual messages, threading them just as they were sent, because they /are/ individual messages. It's only coincidence that the file attachments they happen to contain are all parts of the same much larger file, instead of stand-alone individual files. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/pan-users
