From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Unicode Lisp reader escapes Date: Mon, 22 May 2006 10:33:48 +0900 Message-ID: References: <17491.34779.959316.484740@parhasard.net> <87irohfrx1.fsf@gmx.de> <87iroarr9i.fsf-monnier+emacs@gnu.org> <87d5egrb4c.fsf-monnier+emacs@gnu.org> <87ves8p0us.fsf-monnier+emacs@gnu.org> <87ves8ngtb.fsf@gmx.de> <87u07qcnaa.fsf@gmx.de> <87y7x289lr.fsf@gmx.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1148261680 6454 80.91.229.2 (22 May 2006 01:34:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 22 May 2006 01:34:40 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, storm@cua.dk, alkibiades@gmx.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 22 03:34:33 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FhzJY-0004qI-OH for ged-emacs-devel@m.gmane.org; Mon, 22 May 2006 03:34:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FhzJX-0005Qz-Jh for ged-emacs-devel@m.gmane.org; Sun, 21 May 2006 21:34:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FhzJL-0005Qg-0c for emacs-devel@gnu.org; Sun, 21 May 2006 21:34:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FhzJJ-0005QI-IC for emacs-devel@gnu.org; Sun, 21 May 2006 21:34:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FhzJJ-0005QF-AW for emacs-devel@gnu.org; Sun, 21 May 2006 21:34:17 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FhzN6-0004pH-VA; Sun, 21 May 2006 21:38:13 -0400 Original-Received: from nfs.m17n.org (nfs.m17n.org [192.47.44.7]) by tsukuba.m17n.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4M1Xp50013955; Mon, 22 May 2006 10:33:52 +0900 Original-Received: from etlken (etlken.m17n.org [192.47.44.125]) by nfs.m17n.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4M1Xna3006628; Mon, 22 May 2006 10:33:49 +0900 Original-Received: from handa by etlken with local (Exim 3.36 #1 (Debian)) id 1FhzIq-0001vc-00; Mon, 22 May 2006 10:33:48 +0900 Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sat, 20 May 2006 20:57:25 -0400) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:54983 Archived-At: In article , Richard Stallman writes: > (1) use emacs-mule coding system > (2) use one of iso-2022 based coding systems (they include > iso-8859-X) with setting enable-character-translation to nil > in "Local Variables" section. > (1) works now. (2) doens't work now but easy to make it > work as I wrote in the previous mail. > People have pointed out disadvantages of (1). I don't think that is a big problem because it seems that it's very rare to handle *.el file by some tool other than Emacs. > Maybe (2) is a good solution. Iwant to check, though. It would turn > off *all* character translation. We need to verify that this is ok. I believe it is ok. > Supposing that unify-8859-on-decoding-mode is off, and you read a file > in an iso-2022 coding system. What character translation is done, or > might be done, and in what cases? > In this code, > (defun ucs-fragment-8859 (for-encode for-decode) > "Undo the unification done by `ucs-unify-8859'. > With prefix arg, undo unification on encoding only, i.e. don't undo > unification on input operations." > (when for-decode > ;; Don't Unify 8859 on decoding. > ;; For non-CCL coding systems (e.g. iso-latin-2). > (set-char-table-parent standard-translation-table-for-decode nil) > we turn off the parent of standard-translation-table-for-decode. > But what else might standard-translation-table-for-decode do > for some of these coding systems? standard-translation-table-for-decode is for reflecting any user preferences on decoding. So, it can do anything. If one hates SOFT-HYPEN (U+00AD), he can map it to `-'. The default value of standard-translation-table-for-decode is not nil. It contains a mapping for JISX0208.1978->JISX0208.1980 and JISX0201->ASCII. But, this is to compensate for an encoding used in Japan in vary old time, and even if Emacs reads a *.el file in such an encoding, on writing, the new encoding is used. That means that the mapping is not used when the file is read next time. So, disabling character translation on reading an iso-2022 *.el file effectively stabilize the byte-compiling of the file without any actual problem. --- Kenichi Handa handa@m17n.org