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, p...@foxharp.boston.ma.us (arlington, ma, where it's 65.1 degrees) _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers