Ken Hornstein writes:
We know the format of messages on disk, so that's a non issue. The hair
pulling is in converting terminal input and output to/from a local
display character set. Note that this is NOT the same thing as a locale.
The solution is to mandate utf8 for all input and output. Period. It's
time to recognize it's 2015.
Alright, just so I'm clear:
a) you think we're all crazy (for some definition of 'all')
b) you think we should simply convert the message at read time to UTF-8
and ONLY output UTF-8. Let's call this the 'Plan 9' approach. The
user's locale setting is simply ignored, at least in terms of supported
character set.
I will agree this makes things a LOT simpler. Like tons of code could
be removed. We'd need to import/require an UTF-8 string library; there
are a number of those to choose from. It could be the Plan 9 ones,
libicu, libunistring ... it doesn't matter.
We would be telling everyone if they're not using UTF-8, then we don't
support you.
So what does everything think of that?
--Ken
I'm fine with it. As per my earlier message, times have changed and it's
not clear that we need anything else. Dumb idea... can we push a new
release that announces this to users on first use and allows them to
click on whether or not it's OK?
Jon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers