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: Fri, 02 Jun 2006 20:39:11 +0900 Message-ID: References: <17491.34779.959316.484740@parhasard.net> <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> <87d5e5gwbi.fsf@jurta.org> <87ac8vor6u.fsf@jurta.org> 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 1149248394 26522 80.91.229.2 (2 Jun 2006 11:39:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 2 Jun 2006 11:39:54 +0000 (UTC) Cc: storm@cua.dk, emacs-devel@gnu.org, rms@gnu.org, monnier@iro.umontreal.ca, alkibiades@gmx.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 02 13:39:51 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 1Fm80H-0007Vy-Rh for ged-emacs-devel@m.gmane.org; Fri, 02 Jun 2006 13:39:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fm80H-0003ZR-6k for ged-emacs-devel@m.gmane.org; Fri, 02 Jun 2006 07:39:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fm806-0003ZC-Nt for emacs-devel@gnu.org; Fri, 02 Jun 2006 07:39:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fm805-0003Yz-HK for emacs-devel@gnu.org; Fri, 02 Jun 2006 07:39:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fm805-0003Yw-Ex for emacs-devel@gnu.org; Fri, 02 Jun 2006 07:39:33 -0400 Original-Received: from [150.29.246.133] (helo=mx1.aist.go.jp) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fm86W-0000iQ-UU; Fri, 02 Jun 2006 07:46:13 -0400 Original-Received: from smtp4.aist.go.jp ([150.29.246.12]) by mx1.aist.go.jp with ESMTP id k52BdFZ9020370; Fri, 2 Jun 2006 20:39:15 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp4.aist.go.jp with ESMTP id k52BdDag013333; Fri, 2 Jun 2006 20:39:14 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 3.36 #1 (Debian)) id 1Fm7zj-0001Vy-00; Fri, 02 Jun 2006 20:39:11 +0900 Original-To: Juri Linkov In-reply-to: <87ac8vor6u.fsf@jurta.org> (message from Juri Linkov on Fri, 02 Jun 2006 12:27:01 +0300) 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:55620 Archived-At: In article <87ac8vor6u.fsf@jurta.org>, Juri Linkov writes: >> (2) Accept "char-trans: VAL" in header and local variables section. >> I think "translation: VAL" is too ambiguous. >> (3) Accept "enable-character-translation: VAL" in local >> variables section. > I think using different names in the first line and in the local > variables section is not good. Users may move these settings > between these two places in the same file, and incompatible names > are the source of inconvenience and confusion. Since the variable name > is `enable-character-translation', there should be no problem in using it > in the first line as well. But, wasn't it you who proposed "char-trans"? Eli Zaretskii writes: > But we already do that, e.g. with coding: in the header vs > coding-system in local vars. No, AFAIK we only accepts "coding" in local vars. Anyway, the situation of coding: tag is a little bit different from enable-character-translation case because we don't have a variable for the formar. --- Kenichi Handa handa@m17n.org