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. Agreed. > 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. Agreed. > 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, http://lists.nongnu.org/archive/html/nmh-workers/2013-12/msg00038.html, 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 \ /home/foobar/junk/picture.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 stops? Cheers, Ralph. _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
