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: Several serious problems Date: Mon, 26 Aug 2002 22:17:58 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200208261317.WAA27761@etlken.m17n.org> References: <200208190748.QAA14278@etlken.m17n.org> <200208241211.g7OCBW111768@wijiji.santafe.edu> 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 1030378365 10607 127.0.0.1 (26 Aug 2002 16:12:45 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 26 Aug 2002 16:12:45 +0000 (UTC) Cc: d.love@dl.ac.uk, 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 17jMTs-0002ky-00 for ; Mon, 26 Aug 2002 18:12:44 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17jMyl-0007i4-00 for ; Mon, 26 Aug 2002 18:44:39 +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 17jMV9-0004E3-00; Mon, 26 Aug 2002 12:14:03 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17jM29-0000q5-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 11:44:05 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17jM1B-0000Rx-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 11:43:40 -0400 Original-Received: from gnudist.gnu.org ([199.232.41.7]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jM18-00072M-00; Mon, 26 Aug 2002 11:43:02 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by gnudist.gnu.org with esmtp (Exim 4.10) id 17jJqg-0002xE-00; Mon, 26 Aug 2002 09:24:06 -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 g7QDHwl19971; Mon, 26 Aug 2002 22:17:58 +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 g7QDHw917387; Mon, 26 Aug 2002 22:17:58 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id WAA27761; Mon, 26 Aug 2002 22:17:58 +0900 (JST) Original-To: rms@gnu.org In-Reply-To: <200208241211.g7OCBW111768@wijiji.santafe.edu> (message from Richard Stallman on Sat, 24 Aug 2002 06:11:32 -0600 (MDT)) 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:6913 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6913 In article <200208241211.g7OCBW111768@wijiji.santafe.edu>, Richard Stallman writes: > I'm quite confused with the current status of utf-8.el, > ucs-tables.el, utf-16.el, utf-8-subst.el, etc in HEAD and > RC. > Do you understand the situation in HEAD? I don't understand what exactly do you mean by "situation". I don't know if they are the same as what Dave currently has. I understand how each functions and variables are supposed to work. And, I know that those codes doesn't do definitely wrong thing by reading through the codes briefly. But, I have not checked if they surely works as expected. I believe Dave has done it. And, I don't understand why those many functions/variables are designed as the current way. For instance, (1) Why does loadup.el has this code: (ucs-unify-8859 'encode-only) instead of: (unify-8859-on-encoding-mode 1) (2) Why doesn't utf-8-subst.el provide mappings of non-Chinese characters for ksc, gb, and jisx charsets? The document of utf-8-translate-cjk says as below: ---------------------------------------------------------------------- Whether the `mule-utf-8' coding system should encode many CJK characters. Enabling this loads tables which enable the coding system to encode characters in the charsets `korean-ksc5601', `chinese-gb2312' and `japanese-jisx0208', and to decode the corresponding unicodes into ... ---------------------------------------------------------------------- but, currently only Chinese characters in those charsets are handled. (3) Why is utf-8-translate-cjk a variable, not a minor-mode like unify-8859-on-(de/en)coding-mode? Or, why the latter is not a simple variable? By the way, it seems that once we customize utf-8-translate-cjk to t, customize it back to nil doesn't cancel the translation. (4) It seems that the variable name utf-8-fragment-on-decoding is not appropriate because it is used also in utf-18.el. Perhaps, ucs-fragment-on-decoding is better. (5) It seems that mule-utf-16 can handle the same range of characters as mule-utf-8, but `safe-charsets' property doesn't contain, for instance, `latin-iso8895-2'. Perhaps, this is simply a bug to be fixed easily. --- Ken'ichi HANDA handa@etl.go.jp