[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mikhail
Subject: Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments
Date: Mon, 03 Feb 2014 13:31:55 +0400

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]