--- Jon Steinhart <[EMAIL PROTECTED]> wrote: > So what's the best way to go about this sort of thing? One of the > biggest > handicaps is the absence of any guidance in the form of requirements > or architecture documentation. There's no context for making > decisions on what sort of changes are worthwhile. Can we agree > on some way to work this?
The lack of documentation is a problem, for sure. There's always a danger of breaking a useful feature that the programmer isn't aware of. (My C hacking days are way in the past. I'm saying this philosophically instead of with much real experience.) The old MH book I wrote (it's online now) covers most of the obvious features and some dark corners too. For instance, it discusses the context stuff, how to set and use alternate contexts, and has a simple script called "ctx" for using a different context temporarily. But my guess is that your best resource is the people on this list and on comp.mail.mh -- especially the folks who've used nmh/MH for many years from the command line (not just a front-end that hides some of the "guts"). I'd suggest that before any of us start adding and/or changing nmh features, we post a message about the proposed change and wait a few days for people to react. That seems to be happening now, but I thought I'd just say it. For the long term: I've never written architecture documentation before. How difficult would it be to write one and add to it as time goes on? Would a wiki or some sort of collaborative online setup let us all rough out the outlines of good specs? I don't know. Jerry Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers