Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments

[Mikhail]

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.