From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bugs Subject: Re: decode-char & utf-8-fragment-on-decoding Date: Thu, 5 Sep 2002 10:25:42 +0900 (JST) Sender: bug-gnu-emacs-admin@gnu.org Message-ID: <200209050125.KAA13578@etlken.m17n.org> References: <87y9aii9hc.fsf@cricket.magic.csuhayward.edu> <200209040818.RAA12414@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 1031189068 11539 127.0.0.1 (5 Sep 2002 01:24:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Sep 2002 01:24:28 +0000 (UTC) Cc: tlm@pocketmail.com, bug-gnu-emacs@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17mlNj-0002zz-00 for ; Thu, 05 Sep 2002 03:24:27 +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 17mlPL-00052l-00; Wed, 04 Sep 2002 21:26:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17mlP6-000500-00 for bug-gnu-emacs@gnu.org; Wed, 04 Sep 2002 21:25:52 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17mlP4-0004zi-00 for bug-gnu-emacs@gnu.org; Wed, 04 Sep 2002 21:25:51 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mlP3-0004zT-00 for bug-gnu-emacs@gnu.org; Wed, 04 Sep 2002 21:25:49 -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 g851PhK04511; Thu, 5 Sep 2002 10:25:43 +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 g851Pgd11653; Thu, 5 Sep 2002 10:25:42 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id KAA13578; Thu, 5 Sep 2002 10:25:42 +0900 (JST) Original-To: d.love@dl.ac.uk In-Reply-To: (message from Dave Love on 05 Sep 2002 00:34:51 +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: bug-gnu-emacs-admin@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.bugs:3422 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:3422 In article , Dave Love writes: > Kenichi Handa writes: >> Thank you. It seems to be the right fix. I'll install it >> soon. Dave, do you see any problem with that? > Yes, I think it's wrong. I think the only bug is that the doc string > of `utf-8-fragment-on-decoding' is missing the normal `setting it > directly does not take effect' text for a Custom option with a setter. > It has no effect on how decoding is done, and `decode-char' was meant > to be consistent with how utf-8 decoding actually works. > The translation table is always used -- CCL has no way to access Lisp > variables anyway. It only matters how it's populated (empty by > default). I see your point. Ok, I'll cancel the change, and add this sentence: Setting this variable outside customize has no effect. in the docstring of utf-8-fragment-on-decoding. So, we should regard it a feature that (decode-char 'ucs (encode-char C 'ucs)) will not return C even if C belongs to one of mule-unicode-* charsets. --- Ken'ichi HANDA handa@etl.go.jp