Re: [Nmh-workers] nmh in near, medium, and far-term

[Bill Wohler]

Definitely agree on ditching MM_CHARSET and enabling MIME code
regardless of any locale settings.

MH-E developers: please rack your brains and the SourceForge trackers
for changes to MH that would benefit MH-E. Thanks!

Ken Hornstein <address@hidden> writes:

> Okay, the recent messages about nmh have driven me to write this
> email, but it's been brewing for a while now.  Maybe just getting
> back from the Happiest Place On Earth helped.
>
> Here are my thoughts about what we should be doing with nmh in the near,
> medium, and long(er) term.  In all of these cases, I am proposing that I
> do this work.  I am interested in hearing what people think about this.
>
> - Near term - release, damn it!
>
>   This is driven by the fact that my wife got a new machine at work, and
>   was giving me a hard time about the fact that getting a new copy of nmh
>   on it was a pain.  Okay, this is kind of embarassing.  Having to fetch
>   the sources out of git to get a new release is embarassing.  I propose
>   just taking the current HEAD and making it nmh 1.4.  Also putting a package
>   into MacPorts would be nice.
>
> - Medium term - packaging, Autoconf/Automake cleanup
>
>   As I discussed in previous email, we should do better with packaging.
>   Shipping a spec file with nmh would make sense; other packages do this,
>   why not us?  Also it would be nice to clean up our Autoconf/Automake
>   setup, which is ... not as elegant as it could be.
>
> - Long term - better MIME/charset handling
>
>   Specifically, scan can decode RFC 2047 headers, but it seems that show
>   cannot (okay, mhshow seems to decode some headers, but not others).
>   Also, the whole replying to messages that are quoted-printable
>   or even base64 encoded ... what a mess.
>
>   I am thinking of making the nmh libraries convert all message
>   data upon read into Unicode (specifically UTF-8, but I'd be open
>   to other ideas), and then converting/encoding it as needed upon
>   output.  I am _not_ thinking of changing the on-disk format; inc
>   will still write the original email as received to disk.  These
>   changes would happen to show & friends.  But this would allow us
>   to do a lot saner things with messages that are quoted-printable
>   or base64 encoded (which are more and more of them, unfortunately).
>   If you had a UTF-8 based locale, your life would be a lot happier
>   (I'd also ditch MM_CHARSET, since that seems to be nmh-specific and
>   I see no reason to keep it around).  Now there are a billion and one
>   things to think about here and I haven't looked at the code to see how
>   feasible any of this is; that's why it's marked under "long term".
>
> Anyway, that's what I'm thinking about.  I'm open to other suggestions,
> but please only send them in if you're going to write them (or pay me
> to write them :-) ).
>
> --Ken
>
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
>

-- 
Bill Wohler <address@hidden> aka <address@hidden>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD