Duncan <[EMAIL PROTECTED]> responded: >> I've been using pan for a number of years and love it. One thing >> that has always bothered me about it though is that I cannot view >> the attachment name(s). Is there any way to do that? Sometimes >> I'd like to know what it is before saving it to disk. >There is no such functionality at this point, other than directly >viewing the source of the post (saving that, or opening it from the >cache), and gleaning the attachment name and other particulars from the >raw post. However, I too would find the ability to see that >information, either displayed by default, or at least available, >useful.
Yes, I have been working around this limitation for awhile. I think it would make a great enhancement. >> Another complaint is that posts with attachments don't always appear >> when I have filtering set to only display messages with attachments. >> This is especially true if the message title starts with "Re:". I >> click off "Match Only Complete Attachments" and then they show up. >> I guess pan doesn't see them as complete. > >The problem is, detecting just which posts indeed have attachments is >very difficult, particularly if attempted with only the overview data, >before the post itself has been downloaded. PAN makes its best guess, >based on the title, generally (Does the title have something that looks >like a filename in it? What about part number hints?), but this isn't >always correct, particularly where it comes to replies to a previous >post, where the subject line reflects the original post's content, >giving no hint of what the followup contains. As PAN is currently >coded, it makes the determination of the type of post based, as I said, >on the subject of the post, because that's available before actual post >download. At some point in the future, that could be made more accurate >after download by including a routine that re-checks the downloaded >post content to determine whether it actually is/has an attachment or >not, correcting the little icon as necessary. However, since the main >pain is usually in the downloading itself, the usefulness of such a >feature would be somewhat limited, except in regard to post-download >scoring and the like, if that's ever implemented (currently, scoring >works only on overview content as well, thus preventing one from >scoring on, say, nntp-posting-host, or other useful content or headers >not normally in the overviews). If the NNTP spec had been designed with >binary attachments in mind, things would be very different. However, >the protocol was originally designed for text messages only, and >methods for creating binary attachments are only a crude workaround for >what is still officially only a text based protocol. Thus, basic >information like whether the post is actually text only, or has binary >attachments, and what they may be if so, simply isn't part of the >specifications for the protocol, leaving client software to make its >best guess based on what is after all only community convention, not >part of any formal standard definition, that of putting attachment info >in the subject line. By definition, therefore, any attempt to make >sense of that non-standardized information in the subject and guess at >whether that means there's an attachment and whether it's complete or >not, is prone to mistakes. OTOH, if NNTP /had/ been designed for binary >file transfer, I'm sure it would have been targeted far more heavily by >the copyright violation and censorship crowds... This explains a lot about pan's behavior. Thanks. I looks like a problem for all newsreaders. The method I use to determine if there is a binary attachment is to examine "lines". If it's over 1,000, then more than likely there is an attachment. I have, on occasion, seen messages with 10 lines that have an attachment however. BTW, what does "lines" actually mean? Thanks, -- Wayne. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
