[Top][All Lists]

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

Re: [Nmh-workers] Conflict between "mime" command and attach

From: Ralph Corderoy
Subject: Re: [Nmh-workers] Conflict between "mime" command and attach
Date: Wed, 11 Dec 2013 15:03:17 +0000

Hi Ken,

> The reason this is cropping up now is that we want to get to the point
> where a MIME headers are always generated (I assume this is
> non-controversial).

Looks down.  Mumbles "No".  Scuffs foot.

> Using the tools we have, this means running mhbuild.  This was never
> designed to be run all of the time, hence the issues with directives.


> The reason all of these various suggestions regarding putting mhbuild
> directives in the text feel wrong to me is that it BY DEFAULT assigns
> special meaning to the message body where there was none before.

Yes, a significant change.

> trying to guess what is and isn't a directive suggests to me that
> we're doing the wrong thing.

Yes, and means `#fowr' would go undiagnosed, for example.

> It's fine for users who WANT to create mhbuild directives, but it just
> Seems Wrong that message bodies now assign special meaning to '#' at
> the beginning of the line.


> Can the people who want to have "attach" append mhbuild directives
> explain what their thinking is, specifically why they think their
> approach is preferrable?

You pointed out,
the two paths, starting with mbuild-directives and attach-headers, take
a long time to converge and interfere.  "mime" runs mhbuild, job done.
"attach" puts in the header which is seen late-on by post(8), and only
then constructs mhbuild-directives and runs mhbuild.

The attach-header is a subset of mhbuild functionality.  My suggestion
to alter attach to append mhbuild-directives to the draft was driven by
trying to merge the two paths earlier and without interference.

> Ok, Ralph did say that he wanted to look at the headers
> post-MIMEification to adjust them

No, sorry, when I said "edit" I was referring to a whatnow-entry to put
me back in vi so I can read-only peruse the outcome of "mime".  My
intent is always to have "mime" do the work;  if something's not right I
go back to pre-"mime" and fix it because mhbuild could always do want I
want AIUI.


There seem to be two issues.  `#' is a poor magic character if mhbuild
is to run all the time, clashing too much with unindented cpp(1) and
sh(1) input.  A simple way to attach files shouldn't stop mhbuild
directives being used.  (Personally, I think having `cd', `pwd', etc.,
at the whatnow-prompt for "attach foo" is wrong;  MH's raison d'etre was
to not be its own little shell and whatnow shouldn't grow to be one.)

How about if `#' was configurable and could be multiple characters?  And
that could further be overridden on a per-message basis by an
nmh-header?  The new default could be /^mhb\>/;  something that's
unlikely to be accidental.  Any mhbs that don't parse stop whatnow's
"send" working.

    mhb image/png \
    mhb forw +inbox 42 43 99

A new mhbuild directive that guesses the MIME type could provide a
simple attach mechanism.  whatnow's "attach" could append these instead
of adding its header.  Or still add its header and they're treated as if
they were additional directives at the end of the body in the order
they're encountered.

You're suggesting mhbuild runs on the "send".  Does "mime" then
disappear since mhbuild isn't idempotent?  I'd like some way to inspect
the results of my mhbuild-directives before the email hits the wire.
Would that be a send option that feeds mhbuild-output to $PAGER and then

Cheers, Ralph.

reply via email to

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