Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?

[Joel Reicher]

> > Um, gimme a break here.  Why not just use mhbuild mime-composition files?
> 
> I've been doing that for years, with help from emacs
> functions and key definitions.  Even with that support, I
> still made a copy-and-paste error last week.  And not the
> first time.
> 
> > I added the attachment handling code so that non-geeks could send attachmen
> ts
> > .
> > This is heading in the opposite direction.  How often are these cryptic
> > arguments really going to be used?  How many other mailers care about this
> > sort of stuff?  How many mail programs even look at this stuff?
> 
> While it may not be obvious :-), I want simple, as well.
> And more foolproof.  But I also want configurable.  I know
> that I would never use any of the command line options
> above.  Maybe I should just not bother with them.
> 
> The one thing I do want to be configurable is the build
> directive.  Again, it's not something that I'll change, so
> it can go into my .mh_profile.  But, what's the best way to
> communicate it (currently it has three pieces) to
> make_mime_composition_file_entry ()?
> 
> > If you decide to make these additions, keep in mind that they have to be do
> ne
> > in the send code, not in the whatnow code.  This is because the design of t
> he
> > attachment code was such that it would work independent of the user interfa
> ce
> > .
> > In particular, I know people who have hacked mh-e to add attachment headers
> .
> 
> Got it.  It's easier given nmh's current state, as well.

Perhaps you should create a new utility that writes build directives
and works both interactively and non-interactively, depending on the
command line options? If it is able to write both directives and
attachment headers, whatnow can use it for a *really* versatile way to
attach stuff, and it could also be used from many UNIX editors with
a shell.

Cheers,

        - Joel