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

[Ken Hornstein]

> 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