Re: [Nmh-workers] Renaming Nmh-Attachment to Attach

[Jon Steinhart]

Ken Hornstein writes:
> >I orginally made it settable because I had no knowledge of what other
> >custom headers are out there, especially things that people do with
> >scripts which is one of the strong features of nmh.  I don't care what
> >the default is but would like to have some way to avoid breaking other
> >stuff out there of which I'm unaware since not breaking things is part
> >of the nmh creed.
> 
> Not breaking things is part of the nmh creed?  It wasn't without controversy,
> but I seriously broke things (including, IIRC, your mail setup) when we
> required a From line in drafts.  Also, I broke things for the MH-E people
> when we started processing all component files with mh-format in 1.5.
> 
> Okay, fine.  We don't like breaking things without a good reason.  Here's
> my take on this (in addition to the parts about it being shorter and
> compatible with mutt).
> 
> - In the new world order, we're running mhbuild all of the time (which I
>   know you're not a fan of, but I think you're in the minority on this
>   one, sorry).  This means that there has to be communication between
>   the attach command (in whatnow or whereever) and mhbuild on what
>   header they're using.  This is actually architecturally complicated,
>   especially since you could run mhbuild by yourself.
> 
> - We already have a number of headers which control internal nmh
>   functionality (Envelope-From, Fcc, Dcc), and those aren't
>   configurable.  In fact, the attach header is the ONLY header name that
>   is configurable.
> 
> - The fact that you HAD to configure it before was part of the reason it
>   wasn't wildly adopted.  So having this configurable is confusing.
>   It's better now that there's a default.
> 
> - I am very skeptical that an Attach: header would conflict with what
>   anyone is doing (I mean, really ... what would they be doing?)  It's
>   possible, but "highly unlikely" I think is generous.  I had zero
>   qualms about implementing Envelope-From, and I feel the same way here.
> 
> So, in summary: tougher to implement with new code coming, confusing to
> users, and unlikely to conflict with anyone.
> 
> --Ken

Well hey, I wasn't gonna mention the mail setup thing :)

I have no problem with their being a default.  I didn't put one in originally
because it was a new thing and I didn't want to break anything out there or
surprise anybody.  It was an opt-in thing, and having a default is fine now
that it has legs.

I don't understand why making it configurable is such an issue; the code to
get things out of the profile is pretty straightforward.

But, I don't actually feel that strongly about this, and you who are doing the
work get to decide.

BTW, what stands out to me as the problem in your points above is the ability
for users to manually run mhbuild.  A lot of the grumbling about the original
attach code was about it not being as configurable as mhbuild, and it seems
like changes are in the works to fix this.  So my take is to fix it good and
hide mhbuild in some dark corner.  Oh, and make sure that Norm knows where to
find it :)

Jon