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
