From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: James Cloos Newsgroups: gmane.emacs.devel Subject: Re: X11 Compound Text vs ISO 2022 Date: Wed, 07 Jul 2010 01:19:39 -0400 Message-ID: References: <4C338FB2.3060900@harpegolden.net> <87r5jgnn52.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 1278480039 29199 80.91.229.12 (7 Jul 2010 05:20:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 7 Jul 2010 05:20:39 +0000 (UTC) Cc: emacs-devel@gnu.org, David De La Harpe Golden To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 07 07:20: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 1OWN3g-00054G-Fg for ged-emacs-devel@m.gmane.org; Wed, 07 Jul 2010 07:20:32 +0200 Original-Received: from localhost ([127.0.0.1]:56497 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OWN3f-0008HX-PK for ged-emacs-devel@m.gmane.org; Wed, 07 Jul 2010 01:20:31 -0400 Original-Received: from [140.186.70.92] (port=45259 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OWN3W-0008Gp-9Q for emacs-devel@gnu.org; Wed, 07 Jul 2010 01:20:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OWN3U-000671-Sq for emacs-devel@gnu.org; Wed, 07 Jul 2010 01:20:22 -0400 Original-Received: from eagle.jhcloos.com ([207.210.242.212]:41966) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OWN3U-00066r-PM for emacs-devel@gnu.org; Wed, 07 Jul 2010 01:20:20 -0400 Original-Received: by eagle.jhcloos.com (Postfix, from userid 10) id AE0094016D; Wed, 7 Jul 2010 05:19:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1278480019; bh=n5zuGUt+OoveEEp1RQaNQG9NGHAlyC6dWAkH21bwyvY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=C5i2W8auEepzCWFq7v6BQY5PAMNr6SGy8Dh6IAvutVbwFo+UuRNj+iNGwtNskZr5m T4mCb0k1VBtl19yYiy43d70OeXHSSrxlaGP2zGYh3Y5I6mWObFrOoyPdOSM64GfIL7 9fesiJAAtJhs+07XPS5Pqj9BtbBPJ4KumTc343QA= Original-Received: from carbon.jhcloos.org (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 832DF1C81FD; Wed, 7 Jul 2010 05:19:39 +0000 (UTC) In-Reply-To: <87r5jgnn52.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Wed, 07 Jul 2010 09:36:41 +0900") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Original-Lines: 45 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:126863 Archived-At: >>>>> "SJT" == Stephen J Turnbull writes: SJT> But that goes against the spec, which AFAIK still provides that in SJT> COMPOUND_TEXT the escape to non-ISO-2022 should only be used for SJT> characters not in the repertoires of the registered charsets: SJT> Extended segments are not to be used for any character set SJT> encoding that can be constructed from a GL/GR pair of approved SJT> standard encodings. For example, it is incorrect to use an SJT> extended segment for any of the ISO 8859 family of encodings. SJT> I would argue that you have two choices here: consider the whole SJT> string to be Unicode, and used an extended segment for the whole SJT> thing; or consider the string to be pieced together from segments in SJT> approved standard encodings, in which case a character that can be SJT> represented in those encodings should be. AFAICT, gtk and qt doe the former, and that is really what I was suggesting, except when there is reason for Emacs to beleive that the user may perfer the CJK set. SJT> BTW, for the case of MIDDLE DOT using JIS X 0213, the most recent spec SJT> I could find on the web doesn't admit JIS X 0213 (or JIS X 0212 for SJT> that matter). Exactly the complaint. And even compound-text-with-extensions makes that choice. I'm testing the latter now in xfns.c, but the ctext charsets still need to avoid JIS X 0213. Yes, that seems to fix everything except the usage of 0213. >> The question, then, is how best to do that? SJT> Wouldn't it be better to avoid use of COMPOUND_TEXT targets? How many SJT> apps prefer it to UTF8_STRING? So, for example, when asked for SJT> supported targets Emacs could list UTF8_STRING first. Things are getting better, but ctext is still required for some properties and for interactions with some other clients. I'd prefer UTF8_STRING everywhere, but not to the extent of breaking compatability with the other clients I (and others) use. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6