Re: [Nmh-workers] Items for nmh 1.7

[Jon Steinhart]

Ken Hornstein writes:
> >> So you want the default behavior of mhl to simply dump out the complete
> >> body of a message, without doing any MIME decoding at all?  That just
> >> seems lousy to me, and also incredibly non-useful.  Are people depending
> >> on that behavior?
> >
> >Well yeah, I think that people should have to flip a switch to get the new
> >behavior.  Avoids the "breaking things" surprises.
> 
> The problem I have with that is ... it just sucks.
> 
> I can't imagine that anyone thinks the current behavior of mhn on MIME
> messages is reasonable.  Based on previous experience, I am sure someone
> relies on mhl _not_ doing any MIME parsing, but I can't accept that as
> a reasonable default.  Can you really imagine a new nmh user (okay, we
> don't get many of those, but pretend that we do!) sitting down and coming
> to the realization that to handle pretty much any modern email messages,
> they have to configure something?  That just sounds terrible, and I can't
> really defend that behavior.  That's why now mhshow will now do character
> set conversion by default, as opposed to having to configure every single
> character set you wanted to convert manually.
> 
> Yeah, it may break something; I've written about the balancing act we
> have between trying to maintain backwards compatibility and moving nmh
> forward.  I just don't think having out-of-the-box behavior that is simply
> wrong when it comes to MIME messages is reasonable in this day and age.
> But I'm willing to hear from opposing viewpoints; where we draw the line
> between backwards compatibility and moving things forward (but possibly
> breaking things for people) is something that needs to be decided on a
> case-by-case basis.  So I am interested in hearing what people think
> about changes, and I believe that for every change that I knew would
> break something for someone I did solicit feedback here.
> 
> Unfortunately, the situation we're left with is that nmh really has it's
> roots in MH, but unfortunately development stalled on MH at a crucial
> time when MIME email was starting to take off.  The code was reorganized
> and mhn was split off into a bunch of utilities, but hard decisions
> about what to do with MIME email never got made, and in the intervening
> decades people developed their own workarounds to deal with the lousy
> MIME support.  This is what we're grappling with now.
> 
> >Well you're right, I don't.  And you are a smart-ass :-)  I have thousands of
> >packages installed on my system that get auto-updated daily.  It would be a
> >full time job to look at the release notes for every update.  Not gonna 
> >happen.
> >So in general I prefer packages that fix bugs and add features without 
> >breaking
> >things because I'm trying to get other work done.
> 
> But see, this kind of proves my point.  Wouldn't it have been nice if repl
> just started dealing with MIME email out of the box, rather than you having
> to configure it?  But a huge change like that would have broken something
> for someone.
> 
> --Ken

Well, in this specific case I guess that I could consider it a bug fix so it
would be OK.