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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers