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