Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Lyndon Nerenberg]

> If you are going to assume that all
> INPUT is unconditionally UTF-8, then yes, that would solve this problem.
> But you say above you want to use LANG/LC_CTYPE to convert to UTF-8 on
> input; that would have failed given the problem as stated.

Two problems:

1) original input from the nmh user (composition). What I described works.

2) deciphering any external unlabeled content. this cannot be done reliably. as 
others have said, punt.

3) output well formed content. if we have utf8 internally, we can *always* do 
that (according to the locale()).

> And like I've said before: I think this effort would a) require a new
> library dependency (for UTF-8 processing, since we couldn't use the
> locale functions anymore)

I can (have already) import that from plan9port.

> and b) result in no gain in functionality.

> And last time we discussed this, people screamed at
> the thought of assuming UTF-8 for input; I interpreted that suggestion
> as a non-starter.

But we aren't. I am saying UTF-8 is the native internal character set. What 
happens at the boundaries becomes everyone else's problem.  And after all the 
grief in this discussion over the last five+ years, don't you think it should 
be someone else's problem?