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: X11 Compound Text vs ISO 2022 Date: Fri, 06 Aug 2010 21:50:57 +0900 Message-ID: References: <87hbjeu14p.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1281099074 20375 80.91.229.12 (6 Aug 2010 12:51:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 6 Aug 2010 12:51:14 +0000 (UTC) Cc: stephen@xemacs.org, david@harpegolden.net, emacs-devel@gnu.org To: James Cloos Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 06 14:51:11 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OhMOE-00007x-1g for ged-emacs-devel@m.gmane.org; Fri, 06 Aug 2010 14:51:10 +0200 Original-Received: from localhost ([127.0.0.1]:53069 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OhMOD-0006vD-Jy for ged-emacs-devel@m.gmane.org; Fri, 06 Aug 2010 08:51:09 -0400 Original-Received: from [140.186.70.92] (port=33430 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OhMO8-0006us-B9 for emacs-devel@gnu.org; Fri, 06 Aug 2010 08:51:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OhMO6-0003JY-Mm for emacs-devel@gnu.org; Fri, 06 Aug 2010 08:51:04 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:40545) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OhMO6-0003Il-72 for emacs-devel@gnu.org; Fri, 06 Aug 2010 08:51:02 -0400 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o76CowZP007724; Fri, 6 Aug 2010 21:50:58 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o76CowbE005540; Fri, 6 Aug 2010 21:50:58 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp1.aist.go.jp with ESMTP id o76CovH2022231; Fri, 6 Aug 2010 21:50:57 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.71) (envelope-from ) id 1OhMO1-0004TH-8n; Fri, 06 Aug 2010 21:50:57 +0900 In-Reply-To: (message from James Cloos on Sun, 01 Aug 2010 07:06:22 -0400) X-detected-operating-system: by eggs.gnu.org: Solaris 9 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:128377 Archived-At: In article , James Cloos writes: > The compound text spec shows a 1989 copyright, states that it is > version 1.1 documenting X Version 11 Release 6.8 and notes that > it might be expandepd in the future. > The ctext addtions were clearly added to support additional locales. > And the expansion has stopped thanks to the general shift from iso- > 2022 to iso-10646. > Clearly the ctext spec should have followed along with the reference > code just like, eg, the elisp manual follows the code. > I think it is more than fair to update the ctext spec to document the > current reference code, especially now that the document is old enough > to purchase alcohol in its home country. :) I've just committed a new code to make ctext-with-extensions conform to X's Compound Text spec. As for which charsets to treat as "the standard encodings", I made a variable ctext-standard-encodings and set the default value to this at the moment (i.e. following the current (old) SPEC). ascii latin-jisx0201 katakana-jisx0201 latin-iso8859-1 latin-iso8859-2 latin-iso8859-3 latin-iso8859-4 greek-iso8859-7 arabic-iso8859-6 hebrew-iso8859-8 cyrillic-iso8859-5 latin-iso8859-9 chinese-gb2312 japanese-jisx0208 korean-ksc5601 If we actually find that it is better to follow the current CODE, we can just add more charsets to the variable. The new code was committed to emacs-23 branch, but I don't know when it is propagated to the trunk. --- Kenichi Handa handa@m17n.org