Jon Steinhart wrote: >> While reading much nmh code these days, I also feel that parts of the >> code are ancient. I'd like to support any effort in renewing it. >> >> Autoconf is something I dislike. > >I suppose that I'm willing to do some work here too if I'm not alone. My main >interest, which I expressed years ago, is to figure out what sbr/m_getfld.c is >really doing and rewrite it so that I can add additional functionality without >breaking anything.
I'm not entirely sure what you mean by this. Yes, m_getfld is an incomprehensible piece of code. Yes, it really shouldn't be digging into libc internals in the 21st century. Yes, it has optimisation decisions made based on "what is fastest on my VAX?". But that has nothing to do with implementing better handling of attachments, nicer MIME capabilities or anything else. m_getfld() has a very simple purpose: it lets you read headers and message bodies out of an RFC-822-style text file. You don't need to care about the internals unless they're actually buggy (and I don't know about any current bugs, though I did fix one or two a few years back). It doesn't need any new features because MIME doesn't change the format of RFC-822 messages, it just adds new things piggybacking on top, which the caller of m_getfld will eventually need to parse. Any attempt to rewrite or replace it ought to be preceded by the buildup of the kind of test suite mentioned in the comments in m_getfld.c and subsequently (alas) lost to history. (Some of the code in test/tests/inc is trying to make a start on that.) But if you just want to make nmh's handling of MIME or attachments better or improve its UI, you don't need to spend time doing anything with m_getfld anyway. -- PMM _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
