From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: status of utf-8.el, etc [Re: Several serious problems] Date: Mon, 30 Sep 2002 18:09:22 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200209300909.SAA05081@etlken.m17n.org> References: <200208190748.QAA14278@etlken.m17n.org> <200208291325.WAA03596@etlken.m17n.org> <200208291732.g7THWRU11411@rum.cs.yale.edu> <200209250701.QAA10989@etlken.m17n.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1033377089 21330 127.0.0.1 (30 Sep 2002 09:11:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 30 Sep 2002 09:11:29 +0000 (UTC) Cc: rms@gnu.org, monnier+gnu/emacs@rum.cs.yale.edu, 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 17vwaL-0005XC-00 for ; Mon, 30 Sep 2002 11:11:25 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17vxJw-0001Hi-00 for ; Mon, 30 Sep 2002 11:58:33 +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 17vwaZ-0002AX-00; Mon, 30 Sep 2002 05:11:39 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17vwYm-000237-00 for emacs-devel@gnu.org; Mon, 30 Sep 2002 05:09:48 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17vwYj-00022c-00 for emacs-devel@gnu.org; Mon, 30 Sep 2002 05:09:47 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17vwYc-000224-00; Mon, 30 Sep 2002 05:09:38 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6/3.7W-20010518204228) with ESMTP id g8U99NF27733; Mon, 30 Sep 2002 18:09:23 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.3/3.7W-20010823150639) with ESMTP id g8U99Md01806; Mon, 30 Sep 2002 18:09:22 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id SAA05081; Mon, 30 Sep 2002 18:09:22 +0900 (JST) Original-To: d.love@dl.ac.uk In-reply-to: (message from Dave Love on 27 Sep 2002 14:55:35 +0100) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.1.30 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) 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:8249 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8249 In article , Dave Love writes: > Kenichi Handa writes: >> As the testsuite revealed several bugs, before working on >> RC, I decided to fix them in HEAD at first. I've just installed fixes in HEAD. Could people please test these customizalbe variables. unify-8859-on-encoding-mode unify-8859-on-decoding-mode utf-fragment-on-decoding utf-translate-cjk >> (1-2) utf-8-translate-cjk can never be turned off once >> turned on. > I don't think it should be toggled; Then, why do we have this now? (defcustom utf-translate-cjk nil ...) As far as it's a customizalbe variable, one should be able to turn it off. > is there a reason you'd want to avoid it? One may or may not want select-safe-coding-system to decide utf-8 as the default for a buffer that contains CJK charsets and etc. I'm not sure. > What it needs is to be made more flexible about how the > translation is done, allowing you to prefer Chinese to Japanese, for > instance. Since people moan about the lack of CJK Unicode support, I > hoped someone else would do such work but there's been zero interest > as far as I know... One reason of zero interest is perhaps that such a people is already using Mule-UCS. >> (2-1) As utf-8-fragment-on-decoding and utf-8-translate-cjk are >> also applicable to utf-16, I cut off "-8" from them. > The `utf-8' comes from them being in utf-8.el. At least > utf-8-fragment-on-decoding isn't actually specific to Unicode coding > systems. Sure. If utf(-8)-fragment-on-decoding is non-nil, even if unify-8859-on-decoding-mode is on, cyrillic-iso-8bit, etc shouldn't decode characters into mule-unicode-*. But, I don't have a time to find a better name, and at least, removing "-8" is better. >> (2-2) Make translation table names and their body >> char-tables different to avoid confusion. > As far as I remember, some of the confusion goes away if these are > assumed always to be present, and loaded in the right order. Of course, by disabling the facility of turing them off, we can make things simpler. But, that is not the case at least now. > Some of those names don't seem right. For instance, > ucs-mule-to-mule-unicode isn't only used by utf-8/16 as far as I > remember. ??? So, it doesn't contain "utf". --- Ken'ichi HANDA handa@m17n.org