>A bit less glibly, it might be time to lay down the anchor for the >1.6-branch. I think we have a few more 'breakage' things in the queue >we've been waiting to inflict on the masses ...
Maybe I'm not up on my nautical termology, and I know you sent out a revision that said "1.5", but I'm confused. Is it you're thinking that 1.5 is getting a bit long in the tooth (was released in June of last year) and you want to think about a 1.6, or you want to think about doing more on 1.5? I've idly been thinking in the back of my mind about that. We've got some significant new features already in the current code that should see a release. I'm getting close to done on the newlock branch (it doesn't look like transaction locking will be doable for the context file at least for this go-around, sigh). In a perfect world I'd work on better support for format=flowed, but I don't see that happening. I do want to work on MIME enhancements; the big ones that come to mind are RFC 2047-header _encoding_, content-transfer-encoding selection, changing the default encoding of text parts, support for RFC 2231 encoding on both receiving and sending, auto-execution of mhbuild for all drafts, and actually using the filename in a Content-Disposition header as part of the filename when saving files via mhstore. That would improve our MIME support a lot. I've been thinking that maybe replyfilter should deal better with text; right now it's text formatting algorithm doesn't deal well. I'm thinking that for all text it will have to be handled paragraph by paragraph; if it's mostly "text" with long lines then it gets formatted via par. If it doesn't look like text (e.g., it looks like code) then it gets left alone. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
