> 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
This made sense to me until the last sentence. The particular changes that I want to make involve parsing the mime stuff inside of the 822 style message bodies. I suppose that you could argue that I should make a new function that would parse the bodies. Maybe that's the way to go. Jon _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
