jon wrote:
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?
"allows them to click"... are we talking about the same program? :-)
seriously, i think utf-8-only is the right mindset, architecturally.
if a conversion-to-local-charset step is really needed at the end,
then let it be glued on as a final output library, or as a sed script,
or iconv, or whatever. and then simply apologize for any formatting
or character counting issues that arise.
paul
=----------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 65.1 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers