> 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 _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
