nmh-workers
[Top] [All Lists]

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

2012-01-07 13:38:06
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 <kenh(_at_)pobox(_dot_)com> 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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


-- 
Bill Wohler <wohler(_at_)newt(_dot_)com> aka 
<Bill(_dot_)Wohler(_at_)nasa(_dot_)gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD


_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>