>Actually, I also wonder - how this feature [do not show attachments] >will interact with not calling PAGER multiple times, for each MIME part.
It's important to understand a few things here. For one, I haven't really worked out the details; it's a vague statement. Secondly, there may be some technical issues that muddy the waters (in nmh, there almost always are). But let's step back a bit. First off, I don't think anyone disagrees that the current interface with "mhshow" kind of sucks. Specifically, showing a message with lots of parts kinda bites. Showing a message with a single part kind of bites, actually. So that should be improved. But this gets into a couple of meta-questions about user interface. These are things that nmh has to grapple with, and traditionally we haven't done so well. Generally nmh deals with text, and how to handle that is mostly straightforward. But what happens when you encounter non-text parts, like images, video, or binary content like MS Word documents? You can't really display those in an xterm. So what should we do? Luckily, the standards provide some hints. Here's some text from RFC 2183: Two common ways of presenting multipart electronic messages are as a main document with a list of separate attachments, and as a single document with the various parts expanded (displayed) inline. The display of an attachment is generally construed to require positive action on the part of the recipient, while inline message components are displayed automatically when the message is viewed. A mechanism is needed to allow the sender to transmit this sort of presentational information to the recipient; the Content-Disposition header provides this mechanism, allowing each component of a message to be tagged with an indication of its desired presentation semantics. Later on, it says: Bodyparts can be designated `attachment' to indicate that they are separate from the main body of the mail message, and that their display should not be automatic, but contingent upon some further action of the user. The MUA might instead present the user of a bitmap terminal with an iconic representation of the attachments, or, on character terminals, with a list of attachments from which the user could select for viewing or storage. So it seems consistent to me that at least the default mode with mhshow should not show items with a disposition of "attachment". If people want to add an option to mhshow to make it shows those things, then that's fine with me. I'm just talking about defaults. Also, in general this jibes with my personal experience; items that are marked as "attachment" are stuff you don't want to view directly, but you want to save and look at with another program. Fine, if people want to override that behavior, that's their option. >Does the last one implies, that some kind of meta-message will be >constructed, and if someone send email with few text/x-diff's, for >example, user will see the message and the diff's with one shot of >mhshow? Well, first off ... text/x-diff? Who produces that Content-Type? Fine, there's not really a standard for that. RFC 2046 suggests it's safe to show unknown text subtypes directly to a user directly. The real question is: what's the disposition of those MIME parts? RFC 2183 is silent on what you're supposed to do if there is no disposition header, but I would argue you should default to "inline". >If last one assumption is true, personally, I'd like to see attachments >instead of hiding them by default. And you're free to change that! >Although, for binary ones, it can be >replaced with something useful, like: >[[ attachment: document.doc ]] >[[ type: application/msword ]] >[[ size: 10 Mb ]] That sure would be a lot better than what happens now (you get an error). --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
