Re: [Nmh-workers] nmh architecture discussion: format engine character set

[Paul Fox]

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, address@hidden (arlington, ma, where it's 65.1 degrees)