> > 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.
Subject: issue 42
: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.
Nmh-workers mailing list