From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: Several serious problems Date: 04 Sep 2002 18:15:54 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200208190748.QAA14278@etlken.m17n.org> <200208291325.WAA03596@etlken.m17n.org> <200208291732.g7THWRU11411@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1031159780 23723 127.0.0.1 (4 Sep 2002 17:16:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Sep 2002 17:16:20 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu, handa@etl.go.jp, keichwa@gmx.net, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17mdlL-0006AU-00 for ; Wed, 04 Sep 2002 19:16:19 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17meKc-0004rP-00 for ; Wed, 04 Sep 2002 19:52:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mdmv-0000w5-00; Wed, 04 Sep 2002 13:17:57 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17mdl7-0000nw-00 for emacs-devel@gnu.org; Wed, 04 Sep 2002 13:16:05 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17mdl5-0000nP-00 for emacs-devel@gnu.org; Wed, 04 Sep 2002 13:16:04 -0400 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mdl2-0000mf-00; Wed, 04 Sep 2002 13:16:00 -0400 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 17mdkx-0000jr-00; Wed, 04 Sep 2002 18:15:55 +0100 Original-To: rms@gnu.org Original-Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:7476 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7476 Richard Stallman writes: > Why just Latin-N, and why just as utf-8? > > I am talking about that issue because that is the issue someone > raised. I don't know what other issue there is. Could you tell us? The issue is just the same for the other charsets that have translation tables in the head code, and for other CCL coding systems. For instance, the RC version of mule-utf-8 doesn't translate cyrillic-iso8859-5, and the Cyrillic coding systems don't translate mule-unicode-0100-24ff. > Latin-N character sets are very important in practice. I think the only thing which distinguishes Latin-N is that Latin-1 is (was?) the Internet default and its code points are a Unicode subset. I see no reason to treat, say, Latin-2 as more important than Cyrillic; I guess it has fewer users for a start. I also guess windows-1252 is more widely used than Latin-1, like it or not. > It is also possible that they are easier to handle than some other > character sets (but I don't know whether that is the case here). They're treated identically to the others that ucs-tables handles. You have to work to remove them. (The sets that are handled are just the ones I could conveniently make tables for.) > Is it also a bug that utf-8 can't encode the CJK space or that the CJK > sets can't encode equivalent characters from other sets (which I > haven't tried to address and people probably don't care about)? > > That is certainly a bug. I actually agree with your previous opinion that lack of translations isn't a bug as such, despite what PROBLEMS implied -- the features behave as designed and documented. I definitely don't agree that general lack of unification of Japanese characters is a bug. I got detailed information on the problems with jisx mappings to Unicode, and we were asked not to confuse matters by providing jisx0213 tables in Emacs 22, which is designed not to force that. (The jisx0208 that utf-8-subst.el uses is a case in point, but I assume the Mule-UCS table I used is what Japanese linguists agree on.) It's also not clear that one should unify double-width characters with iso8859, for instance.