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 <[email protected]> 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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/nmh-workers > -- Bill Wohler <[email protected]> aka <[email protected]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
