[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] repl and mime handling

From: Ken Hornstein
Subject: Re: [Nmh-workers] repl and mime handling
Date: Wed, 18 Jan 2012 12:16:57 -0500

>For English-speaking countries UTF-8, in majority, means ASCII,
>they can see no difference. As an advantage they can use foreign
>names like Moebius in original, this makes message more readable. 
>But I'm afraid they wouldn't be happy with message written in
>Russian, Chinese or Korean. 

Well, I can't speak for anyone else, but I can handle UTF-8 fine
(I got some spam recently in some variant of Arabic and it displayed
just fine).

>In fact, I know very little about API, so it might be difficult.
>But restrict the entire nmh to utf-8 charset would cripple system.

It's not a "restriction", per se ... it's more about the internal
representation.  It's easy enough to call iconv() (or whatever) to
convert UTF-8 to and from the native character set.

>Beside the information on charset inside API, from my point
>of view the correct, and too much resource consumig, is move out
>module for conversion outside, as separate program. The default
>program would convert to utf-8, but anyone can provide his own
>program for conversion according to his taste. Suppose an entry in
>.mh_profile mh-text-convert: prog

Yeah, that's doesn't really solve the problem in any meaningful way.
Conversion isn't the problem (most Unix systems today have access to
an API which does that for you).

There is a good chunk of code inside of nmh that assumes ASCII (in
terms of "what is a space", "what is a newline", and other things).
Given the existing APIs today, handling multiple character sets
within this code would require a lot of work.  That's why I am
proposing making the internal representation UTF-8.  Now my plan
was to convert from UTF-8 to the native character set, but that
conversion won't be perfect.

So here's my general feeling: since I'm writing the code, I'm the one
who makes the decisions.  If you (or anyone else) wants to write the
code, then hey, you can make the decisions - you won't hear a peep
out of me.  Otherwise, you can give me your OPINION, and I'll listen to
it, but I'll still be the one making the ultimate decision.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]