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, 30 Jul 2010 10:27:20 +0900 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1280453256 12994 80.91.229.12 (30 Jul 2010 01:27:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Jul 2010 01:27:36 +0000 (UTC) Cc: emacs-devel@gnu.org, david@harpegolden.net To: James Cloos Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 30 03:27:35 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 1OeeNq-0004Jp-D8 for ged-emacs-devel@m.gmane.org; Fri, 30 Jul 2010 03:27:34 +0200 Original-Received: from localhost ([127.0.0.1]:59647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OeeNp-0000fT-Py for ged-emacs-devel@m.gmane.org; Thu, 29 Jul 2010 21:27:33 -0400 Original-Received: from [140.186.70.92] (port=36600 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OeeNk-0000eq-4f for emacs-devel@gnu.org; Thu, 29 Jul 2010 21:27:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OeeNi-0000pI-IU for emacs-devel@gnu.org; Thu, 29 Jul 2010 21:27:28 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:60756) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OeeNi-0000ox-1v for emacs-devel@gnu.org; Thu, 29 Jul 2010 21:27:26 -0400 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id o6U1RLtA006293; Fri, 30 Jul 2010 10:27:21 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id o6U1RLoa011929; Fri, 30 Jul 2010 10:27:21 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp2.aist.go.jp with ESMTP id o6U1RK0E007365; Fri, 30 Jul 2010 10:27:20 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.71) (envelope-from ) id 1OeeNc-0003ke-Pt; Fri, 30 Jul 2010 10:27:20 +0900 In-Reply-To: (message from James Cloos on Thu, 29 Jul 2010 11:51:21 -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:127996 Archived-At: In article , James Cloos writes: KH> And, anyway ctext is not used for selection, > I has to be used for X selection, yes? No. > How else could X selection of > text work than using data tagged with X's STRING, COMPOUND_TEXT or > UTF8_STRING atoms? iso-8859-1, ctext-with-extensions, utf-8 respectively in this order. KH> I'd rather just document that ctext is not fully compatible X's KH> COMPOUND_TEXT spec, but is the extended vesion. KH> For WM_NAME, etc, yes, we should use ctext-with-extensions, KH> and as ctext-with-extensions is not intended to be used KH> directly by users, I think it won't cause actual problems KH> even if we change it so that more characters are encoded KH> using UTF8-extended-segment. So, I'll work on it soon. > ctext-with-extesnions already supports the UTF8 extended segment; the > bug is that it uses JISX 0213 for some characters. The earlier JISX > versions (0201, 0208 and 0212) are OK, but 0213 is not. Yes, I understand that. My intention is to modify (or fix) ctext-with-extesnions to use UTF8-extended-segment for characters that doesn't belong to any of few legacy character sets listed in the spec of COMPOUND_TEXT. KH> The only problem with ctext-with-extensions is that it is KH> now implemented by Elisp, and thus it may cause GC. I'm not KH> sure it is safe to call Lisp at the place we convert WM_NAME KH> etc. If it is not safe, I'll implement KH> ctext-with-extensions in C. > the WM_NAME code already has to gc protect to do the conversion to utf8 > for the gtk call (when compiled for gtk) and the new code to set the > UTF8_STRING _NET_WM_NAME and _NET_WM_ICON_NAME properties; I presume it > could do a conversion to ctext-with-extensions within that same protect? Ah, then, perhaps so. By the way, the spec of COMPOUND_TEXT (included in xorg-docs-1.5) lists these registered charsets. ISO8859-1 ISO8859-2 ISO8859-3 ISO8859-4 ISO8859-5 ISO8859-6 ISO8859-7 ISO8859-8 ISO8859-9 JISX0201.1976-0 GB2312.1980-0 JISX0208.1983-0 KSC5601.1987-0 but libX11-1.3.2/src/xlibi18n/lcCT.c lists many more charsets (e.g. more 8859 series and all CNS11643 series). I think it is better to follow the above spec than lcCT.c. What do you think? --- Kenichi Handa handa@m17n.org