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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers