[Top][All Lists]

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

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

From: Lyndon Nerenberg
Subject: Re: [Nmh-workers] nmh architecture discussion: format engine character set
Date: Tue, 11 Aug 2015 18:34:59 -0700
User-agent: K-9 Mail for Android

>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

No. The message must remain in its original format. But as we process it 
internally, we do so as utf8. So I guess my answer really was yes.

>   and ONLY output UTF-8. 


> Let's call this the 'Plan 9' approach.  

If you like. Plan 9 is so 1980s in this regard. I would rather call it 21st 
century :-)

>user's locale setting is simply ignored, at least in terms of supported
>   character set.


>We would be telling everyone if they're not using UTF-8, then we don't
>support you.

In the sense that we don't support your character set encodings, yes. In the 
sense that we won't design interfaces to at least try to make it palatable for 
you to provide your own character set conversion glue? No.

But the bottom line is utf8 is here to stay, and the other character sets will 
become historical artifacts. It's absurd to spend thousands of lines of (new) 
code supporting them. 

That problem space lives well outside of nmh. The people to rightly fix it are 
the xterm authors, and people writing keyboard drivers. These conversion layers 
belong inside the terminal I/O drivers, where they can fix the problem for 


reply via email to

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