Hi Ken,

> > Incompatible change, I realise.  Just trying to step back a bit and
> > see why we ended up here.

That was more explaining my meanderings rather than asking the question.

> There are a couple of things going on here.  One is, like you said,
> headers tell nmh programs what to do.  These are user-editable, and in
> cases of things like "To: and "cc:" users are expected to edit them.
> The other part is we're now using more headers as an IPC mechanism
> from one set of nmh programs to another.  There was always some of
> this, of course - repl(1) sets the To: and/or cc: headers, but now we
> are starting to make use of this for things like attach, and the
> proposal for forw(1).  These can also be user-editable, and I think
> that's desirable.  There will probably be more of them.

I think you end up in the second paragraph saying Attach, etc., fall
into the same bucket as the first's, which is how I lumped them
together.  That just leaves headers that nmh doesn't read or write at
all.  Bar any of those getting out by accident and we'd be half-way

Here's that colon-prefix idea again.  Any header without has to be in
nmh's domain.  `To' is, even if the out-going email happens to have one
of the same name;  nmh gets in there for the aliases, encoding, etc.
The issue tracker wants an Attach header if I'm trying to attach a file
to an existing issue.  By using the colon prefix I'm stating it's a raw
mail header outside of nmh's purview and it's automatically got its own
namespace distinct from nmh's prefix-less one.

    To: bughunter
    From: ralph
    Subject: issue 42
    Attach: core
    :Attach: Obtained on Arch Linux with s-nail 14.8.10-1.

As for being incompatible, Python had that `from __future__ import'
thing, Perl has `require 5.042', and .mh_profile could probably grow
something to keep *old* behaviour so new users, and old users that don't
experience breakage, get new behaviour.

Cheers, Ralph.

Nmh-workers mailing list

Reply via email to