Re: [nmh-workers] To/cc decode or not to/cc decode

[Ken Hornstein]

>> people don't update their config files because they put in them in
>> place 20 years ago and they worked fine
>
>That includes me.  When I've time, I need to clear them all out and
>start from scratch to see what's needed and the best way to solve
>problems, using a new installation in a second account as a guide.

Right, but ... the fact that you haven't YET done that I think just
bolsters my point.

It's like when someone complains, "Oh, I've been seeing this garbage in
my scan output for years now, will nmh ever deal with it??" and we all
point out, "Hey, it's LITERALLY been dealing with that since the first
release of nmh" and it turns out the problem is they put in place their
own custom scan format back in the 80s and haven't updated it since.
If this just happened once, fine, but it keeps happening and that sure
suggests to me that we're approaching this wrong.

>> so changing the default templates isn't as helpful as one would think.
>
>It's a good form of documentation.  In particular, I think it would be
>helpful to spell out to users how they can get a ‘pristine’ set of
>.mh_profile, etc., that they can set an environment variable or two to
>so it's used instead of their unharmed ones from last millennia's.

Oh, I agree that having the templates as an example is helpful as
documentation; we've tried to make some of the default format files
have a bunch of comments explain what is going on.  It just doesn't
help the user who changed their files a decade or two ago and hasn't
had the time or inclination to update things.

>> Clearly the default should be decoded header fields unless a user
>> explictly asks for them unencded.
>
>I don't see how that's compatible with access to the lossless raw ones
>unless both are kept around.

Well, "kept around" is sort-of vague, especially when we're talking about
something as vague as a hypothetical future API which hasn't really been
designed yet :-)

But, here are my thoughts in that regard.  It seems like most USERS of
header fields want the decoded, "unfolded" field.  So obviously any
API should provide that.  I think when you specify a component field
in a mh-format file by default it should give you the decoded component.

But there are cases when you want the undecoded fields.  The most
obvious one I can think of is when generating replies; for various reasons
when you are inserting email addresses into the reply draft the most
reliable thing is to use the "raw" address without any decoding.
I'm sure there are others that I am not thinking of.  But I wouldn't
worry about the features (or lack thereof) of some future undefined
and unimplemented API; if we need to change things that would be easy
to do!  Because, you know, it hasn't been written yet :-)

And I hope it goes without saying that this wouldn't be touching the
on-disk format of messages.

>I may have suggested this before, but shipping a folder of test emails
>that a user can ‘scan +/usr/share/nmh/...’, etc., as a test of their
>configuration, along with pre-formatted ‘golden’ output would be an easy
>way for them to check they've updated to the latest bell and whistle.

That might be useful, although the classic problem of letting people
know that such a thing exists is a always an issue.

--Ken