>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
