[Top][All Lists]

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

Re: [Nmh-workers] New mhbuild directives

From: David Levine
Subject: Re: [Nmh-workers] New mhbuild directives
Date: Wed, 14 May 2014 22:41:55 -0400

Lyndon wrote:

> How can an inline header specify where to inline the content?  The
> point of inline is to display the content in the context of the
> location of the inlined MIME part.  I.e. right *here* where I invoke
> it.

I don't read that from RFC 2183, just that inline means
"intended to be displayed automatically upon display of the
message" and "presented in the order in which they occur".

So, it makes sense to me that inline text/calendar parts are
automatically fed directly to a calendar program.  I don't
appreciate why gmail handles message/rfc822 attachments the way
it does or doesn't.  Even if we could get it "fixed", I suspect
it won't be the last time we run into something similar.

Back to the "Attach and disposition" subject, I don't want to
lose sight of this:

# it's a shame to have to foist the decision as to which to use
# (Attach or Inline) onto the user.

I, for one, would appreciate if nmh captured the knowledge that
message/rfc822 parts should be sent inline to gmail.  I'm not
sure how other than based on MIME type.  I don't send
message/rfc822 often and would be fine with defaulting it to
inline, but I don't know how others feel about that.

Ken, when you first mentioned "a more generic mechanism", I was
thinking along the lines of
"mhbuild-disposition-<type>/<subtype>: inline" profile entries.
mhn.defaults could provide those for text/calendar and possibly
message/rfc822.  Users could override as they wish in their

Forcing every nmh user to learn all the exceptions, and remember
them every time they Attach:, is as user unfriendly as we could


reply via email to

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