[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ralph Corderoy
Subject: Re: [nmh-workers] To/cc decode or not to/cc decode
Date: Wed, 17 Jul 2019 14:43:11 +0100

Hi Ken,

> > Because MH lets us arrange things how we want so if decoding was
> > done by default we'd need a means to get to the raw original version
> > instead, e.g. I want to scan or pick them based on the raw value.
> > Given decoding isn't lossless, this suggests both the original and
> > decoded would need to be kept.
> I can VAGUELY imagine a situation where you might want to search
> undecoded header fields, but I have to believe it is NOT the normal
> behavior

I didn't suggest it's the normal behaviour, even for me.  :-)

> (also, I think a tool to search undecoded header fields already exists
> and it's called grep).

That doesn't work since fields can be across multiple lines.  And I said
scan and pick, not so not just search.

> > Instead, and rather than apply the negative un-decode, my feeling is
> > the decode should be explicit.  We can provide default
> > configurations that apply for it new users, much as we are now.
> 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.

> 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.

> 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.

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.

Cheers, Ralph.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]