Ken Hornstein writes: >>1) when you use show on a range of emails, and if they're all >> non-mime ones, output is very pleasant and comfortable - every >> message is indented and given a nice header with its number (it's >> very useful for replies). It's very convenient to use with 'pick', >> for example to read whole thread in mailing list with "show `pick >> -subj <subj>`". But whenever even one message is MIME, even if it's >> only text/plain - all chain starts to be processed with mhshow. > >So, that's not _exactly_ true. You can, for example, add -nocheckmime >to show to suppress that behavior (also, at least for 1.5, set NOMHNPROC >in your environment). Of course you get no decoding of the message body >when you do that.
Thanks for the prompt! >> I managed to escape from <press enter> for headers with mhshow: >> -nomoreproc, but I can't get the same eye-plesant result as with >> non-mime messages. >> >> Does anyone ever scripted a solution for this with metamail or >> anything like this? Or what can you advice to read a chain of MIME >> messages in a manner 'show' does (with messages numbers/indents)? > >Sigh. It's unfortunate, but right now "mhshow" pretty much sucks. My plan >is to make things much better for 1.6 (but it still won't be exactly where >I want). Right now there is no good answer in 1.5 (or even in the git >tree). Can you give an insight into targeted behavior for 1.6 and what is your "ideal" behavior look like? >>2) When I reply with non-english text to an email, and attach a file >> to the reply, final message is a multipart MIME, and text part is >> octet-stream, I checked git (1.5 here) - seem it's fixed there, >> much thanks for that, nevertheless, is it possible to make those >> 'text' parts of the reply as 'Content-Disposition: inline' somehow? > >Let me understand you, so there's no confusion. You're saying that you >repl to a message, you include non-ASCII characters in your reply text, >you use the "attach" command, and the text part of your message ends up as >an application/octet-stream? Seem I've mixed two questions in one. Yes, you've described situation correctly, and solution you suggested works, thank you! But also, I would like to add 'Content-Disposition: inline' field to the first 'text' part of the message the way mutt it does for example, to clearly specify that this part has to be shown in a context. I've bad feeling that some nasty email clients will interpret text part as an attachment. _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
