I may be alone in this, but I'm a more traditional Unix user. If there
is something that doesn't work the way I want, I use a filter... For
this particular problem, would iconv(1) work to convert texts from one
encoding to the other? Maybe iconv support could be integrated as a
command to run for support rather than a library linkage?
Sigh. It's more complicated than that.
Character set conversion happens in a number of places; not just in
message bodies (which is actually new support in nmh) but also in
message headers (support has been around for a while) and in extended
MIME parameters (new in 1.6). Calling a filter for those things just
seems rather crazy to me. Also, makes things more complicated (if
you're calling the iconv() library, you can determine at that point if a
character set is invalid; would be harder in a filter). So I don't
see the gain of using iconv as a filter.
The goal here was to have nmh, out of the box, be able to deal with
emails that come in with non-native character sets. We're closer to
that but not perfect yet.
One of my plans for the "new MIME" architecture was to permit the usage
of a custom character set converter; you could use your own filter, if
for some reason you wanted to. The default would still be an internal
linking to iconv (and we'd still require it). Although that's not top
on my list of features.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers