[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: Ken Hornstein
Subject: Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments
Date: Mon, 10 Feb 2014 16:02:49 -0500

>... if I receive "disposition: attachment" which can be safely viewed in
>my terminal (like in the above example, text/x-diff, btw, Mutt produce
>such content-type) wouldn't it be nice to save me mhlist/mhstore steps
>and just display it inline (by default)?

Are you sure Mutt actually produces that type internally, or simply
allows people to set that as a Content-Type?  I mean, you can send
text/x-diff with nmh messages as well.

Here's the problem.  The Content-Disposition header is designed to
provide a hint for MUAs in terms of what to do in terms of the display
of a particular MIME part.  When it's set to "attachment", it's a suggestion
that means "Hey, don't display this by default".  So now, you're asking
to pay attention to that hint (which is good) ... EXCEPT for one particular
MIME type (one that's actually a rather lame one).  So, I'm having a hard
time thinking this is a problem.

Putting that aside ... I see some challenges.  Specifically, what would
the configuration for this change look like?

>Also thinking about it I just caught myself: now nmh allow you specify a
>program for mhshow to call, to "show" you attachments, if my
>understanding is correct, and nmh is moving towards mhlist/mhshow
>approach this feature will be removed?
>Or there is intention to save this feature and just add a switch
>"display this type of attachment or hide them" to msshow-show-* profile
>entries? And therefor task from above paragraph can be achieved with
>just specifying 'cat' as a program to mhshow-show-text?

Sigh.  I haven't worked out those details yet.  That's part of the point
of these messages, of course ... to flesh out the annoying details :-)


reply via email to

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