From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thomas Morgan Newsgroups: gmane.emacs.bugs Subject: Re: decode-char & utf-8-fragment-on-decoding Date: 05 Sep 2002 21:13:21 -0400 Sender: bug-gnu-emacs-admin@gnu.org Message-ID: <87k7lzq5se.fsf@cricket.magic.csuhayward.edu> References: <87y9aii9hc.fsf@cricket.magic.csuhayward.edu> <200209040818.RAA12414@etlken.m17n.org> <87vg5lovra.fsf@cricket.magic.csuhayward.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1031275107 28062 127.0.0.1 (6 Sep 2002 01:18:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 6 Sep 2002 01:18:27 +0000 (UTC) Cc: handa@etl.go.jp, 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 17n7lR-0007IU-00 for ; Fri, 06 Sep 2002 03:18:25 +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 17n7n6-0003Ha-00; Thu, 05 Sep 2002 21:20:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17n7mP-0003Fs-00 for bug-gnu-emacs@gnu.org; Thu, 05 Sep 2002 21:19:25 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17n7mM-0003FY-00 for bug-gnu-emacs@gnu.org; Thu, 05 Sep 2002 21:19:24 -0400 Original-Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17n7mM-0003FU-00 for bug-gnu-emacs@gnu.org; Thu, 05 Sep 2002 21:19:22 -0400 Original-Received: from user-2ivebi1.dialup.mindspring.com ([165.247.46.65] helo=cricket.magic.csuhayward.edu) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17n7mH-0002yD-00; Thu, 05 Sep 2002 18:19:17 -0700 In-Reply-To: (message from Dave Love on 05 Sep 2002 23:47:44 +0100) Original-To: d.love@dl.ac.uk Original-Lines: 77 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:3438 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:3438 > Right now it applies > to CCL programs, but not to decode-char. Is that correct? I don't know what `it' refers to there. The option `utf-8-fragment-on-decoding'. utf-8-fragment-on-decoding's Custom set function changes the element of translation-table-vector named `utf-8-translation-table-for-decode'. CCL programs use this same table from translation-table-vector. Therefore, utf-8-fragment-on-decoding applies to CCL programs. On the other hand, utf-8-fragment-on-decoding's Custom set function does not change the value of the variable `utf-8-translation-table-for-decode'. decode-char uses this variable's value. Therefore, utf-8-fragment-on-decoding does not apply to decode-char. Is this because utf-8-fragment-on-decoding is meant only to apply to user-level operations like finding a file or reading email, but decode-char should be counted on always to return the same result to Lisp programs even when user-level options change? * * * > If it is not correct, however, how about making decode-char look for > utf-8-translation-table-for-decode within translation-table-vector > rather than accessing the Lisp variable directly? I don't understand. This would be a change from the current behavior, and I'm not sure whether it is right or wrong. But when you said 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). it seemed to me that decode-char should use the same translation table that CCL uses. I just learned that this table, as well as being found in translation-table-vector, is also the value of the `translation-table' property for the symbol `utf-8-translation-table-for-decode'. It is not, however, necessarily the value of that symbol's variable definition. So instead of (if (and c (aref utf-8-translation-table-for-decode c)) (aref utf-8-translation-table-for-decode c) c))))) maybe decode-char could do something like (let ((table (get 'utf-8-translation-table-for-decode 'translation-table))) (if (and c table (aref table c)) (aref table c) c)) * * * I don't know what you think needs documenting -- can you suggest text? I realized that you were right to put the explanation in decode-char rather than utf-8-fragment-on-decoding, and thought that the following would make the situation more clear, > (Note that this char table is independent of the translation table > of the same name which CCL programs use, and it is not affected by > the user's setting of utf-8-fragment-on-decoding.) but I must have misunderstood the facts. That seems to be the opposite of how it actually is. Could you explain how it actually is? I'm sorry to take up your time with something that is surely not as important as your other activities. I would also like to express as a user great thanks to you and all the Emacs developers!