Steven wrote: > That's probably a helpful thing to do, but the question I was wondering > about wasn't why the UTF-to-UTF conversion was reported, but rather why > the iso-8859-1-to-UTF conversion wasn't reported.
Ok, commit 41ce4490ac5d might fix the problem for you. The cause was mismatch between the character set of content generated by the external program (lynx, in this case) and mhfixmsg -textcharset UTF-8. mhfixmsg wasn't capturing the charset of the generated output, assuming it was unchanged. It then converted it again. The fix is for mhfixmsg to detect the charset of the content, using file --brief --mime-encoding if it can. If it can't, it falls back to the -textcharset value. If that wasn't used, it gets it from the locale and advises the user. I'm not completely sure that this will fix your problem because it's aimed at added text/plain parts. But with -noreplacetextplain I think that's the path to your issue. I also added -display_charset UTF-8 to the mhn.defaults config for lynx, based on the assumption that that's what most users want. Maybe it would be better to leave the charset unchanged at that point and have iconv convert it later. But that would lead to requiring a -textcharset to determine the final charset. David