Okay, so I am thinking that perhaps we are close to ready to start the 1.5 release cycle; I don't have anything else on my plate that I'd like to see in there. So if anyone else has any code they would like to see in nmh for 1.5, now is the time they should speak up! And just so there's no confusion ... what I really mean is, "if YOU have any code"; in other words, if you have code you have written or would like to write, then you should definitely speak up. If you are talking about code you would like someone ELSE to write, then I would kindly suggest you NOT speak up at this time; I think it would be more appropriate for those things to wait until after 1.5 is branched. Bug reports are of course welcome even without code. Now of course the one thing that people have repeatedly asked about is better MIME handling when dealing with replies. Believe me, I feel your pain. But I think I have a reasonable solution and I'd like some feedback on it. I've been living with "par" as my formatproc for a while now, and for simple cases it's been great. But it has some unfortunate side effects. It works "okay" on more modern messages designed to be reflowed (although I still get q-p equal signs sprinkled throughout the message). But for already-repl'able messages, especially ones with source code in them, it really chews them up. So it's good for some things, not so good for others. But that got me to thinking - maybe I could have a more intelligent formatproc that could handle MIME? Since the formatproc only has access to the message body (don't ask; that is NOT easily fixable), you missed out on some crucial headers that described the MIME content. To make a long story short, I extended the mhl filter syntax so you could give arguments to the filter program, and the arguments are mh-format strings that have access to the message headers. Based on THAT support, I've cooked up a semi-intelligent MIME filter, written in perl, and I've appended it below. The comments at the top explain how to use it. It should do the "right" thing with text/plain content and put markers in for non-text content. It should also handle nested multipart messages. Feedback is welcome; you'll need a pretty recent nmh (March 20th or newer) to make a go with it. You'll also need the MailTools perl package as well. It's probably a bit fragile; I haven't tested it all that much yet, but it worked for some of the more complicated messages that I have. If people think it's a good idea I wouldn't mind shipping this with nmh, but I'm not sure where is should go; right now nmh doesn't have a dependency on perl. We could always put it in the "docs" directory. Anyway, please let me know what you think! --Ken
replyfilter
Description: Text document
_______________________________________________ Nmh-workers mailing list Nmh-workers(_at_)nongnu(_dot_)org https://lists.nongnu.org/mailman/listinfo/nmh-workers