Thus said Ken Hornstein on Fri, 06 Feb 2015 09:03:17 -0500: > 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.
Right, this is the behavior I would expect. If it cannot convert, then just dump the characters (or perhaps substitute, which is a fair effect to be making given that it is probably safer to do than just the raw bytes). When I browse to a website that has characters my encoding doesn't understand it puts a box-like character in place of the actual character. It's an annoyance, but better than no data at all. > Now, the thing that David and I don't understand is ... what, exactly, > is the problem with setting an UTF-8 locale? Because everything else I use works with my current locale, which means I have to either change the locale for everything else, or make an exception for nmh, which previously didn't care what my locale was, and it would just make a best effort. Personally, I didn't mind the weird characters (I primarily use EXMH so the occasional viewing of an email that didn't quite render correctly was not a problem)---I can easily ignore characters that don't turn into words. > But the previous nmh behavior was so wrong we really didn't have much > of a choice here. I understand that. At any rate, I'm probably alone in this, so it's not worth debating at this point. I will find a way to make it work (either using an environment variable for invocations of show/next, or removing iconv support from nmh). Thanks for taking the time to respond. Andy -- TAI64 timestamp: 4000000054d653c5 _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
