>But, I've never had to do that before (I was using nmh-1.4). I'm trying >to avoid the prospect of changing my locale and just have mhshow output >data as it did before. I suppose if it comes right down to it, I could >put a wrapper around show/next, etc...
To expand on what David said, but to put it more clearly: nmh, prior to 1.6, got it wrong. We now get it less wrong (but still nmh 1.6 isn't perfect). Before, you could set the environment variable MM_CHARSET to tell nmh what character set you supported. That existed because MH was around before locales were invented. But now the way you indicate to all applications which character set you support is via locale settings. So now nmh uses the locale settings. That's a good thing! We're behaving like other Unix applications now! >The previous version of nmh on my system didn't bother with conversion >(at least not to my knowledge) and would naively just output the >text/plain portion and let my terminal figure out what to do with >it (which occasionally left some characters unreadable, but it was >sufficient for my needs). It seems now that nmh is trying to be more >selective about what it shows rather than just being liberal about it >and showing me what is in the file. Either that or previously nmh was >more successful at converting the UTF-8 to US-ASCII. Well, you've got it kind-of right ... what it did before was just output stuff by default. You had to manually configure any character set conversion and most people never bothered, and frankly I always found the fact that you had to configure that basic function rather ridiculous. So now character set conversion happens by default. The consensus on the mailing list was that both of these things (automatic character set conversion and getting your supported character set via the system locale) were definitely the right approach. The basic problem here is: 1) You indicate via locale settings that the character set you support is US-ASCII. 2) nmh gamely tries to convert UTF-8 characters into US-ASCII, and fails. 3) We output an error message. The real problem, from my perspective, is 3) ... what we should do is what every other email program on the planet does and simply substitute a character instead of just fail. So, we're not where we want to be, but we're getting better. Now, the thing that David and I don't understand is ... what, exactly, is the problem with setting an UTF-8 locale? I kind of thought you had to work to make that not happen, but maybe some systems don't make that the default. If it's just generic grousing about how you didn't have to do that before ... okay, fine, I get that. I wish we could make it so no one ever had to change anything to make nmh work every time a new version comes out (I know Jon Steinhart doesn't believe me, but it's true! :-) ). But the previous nmh behavior was so wrong we really didn't have much of a choice here. If there is some reason you can't set the locale, we'd be intersted in hearing about it. But seriously, if your terminal can handle UTF-8 fine, you _should_ have an UTF-8 locale set. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
