From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel,gmane.mail.mew.general Subject: Re: [mew-int 01596] Re: windows 1252 Date: Thu, 13 Nov 2003 10:01:57 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200311130101.KAA04554@etlken.m17n.org> References: <87llqzuvaj.fsf@tleepslib.sk.tsukuba.ac.jp> <20031104.111334.60445673.kazu@iijlab.net> <200311070713.QAA24793@etlken.m17n.org> <20031110.161123.49979847.kazu@iijlab.net> <200311100742.QAA29290@etlken.m17n.org> <87ekwdilwx.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: deer.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 1068685592 30627 80.91.224.253 (13 Nov 2003 01:06:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 13 Nov 2003 01:06:32 +0000 (UTC) Cc: mew-int@mew.org, kazu@iijlab.net, d.love@dl.ac.uk, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Nov 13 02:06:28 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AK5wJ-00053N-00 for ; Thu, 13 Nov 2003 02:06:27 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AK5wJ-0007VP-00 for ; Thu, 13 Nov 2003 02:06:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AK6rc-00050a-W2 for emacs-devel@quimby.gnus.org; Wed, 12 Nov 2003 21:05:40 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AK6qY-0004l7-9e for emacs-devel@gnu.org; Wed, 12 Nov 2003 21:04:34 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AK6pv-0004Yu-Fn for emacs-devel@gnu.org; Wed, 12 Nov 2003 21:04:26 -0500 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AK6pu-0004YU-Ne for emacs-devel@gnu.org; Wed, 12 Nov 2003 21:03:54 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/3.7W-20010518204228) with ESMTP id hAD11wh05717; Thu, 13 Nov 2003 10:01:58 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6/3.7W-20010823150639) with ESMTP id hAD11vs07984; Thu, 13 Nov 2003 10:01:57 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id KAA04554; Thu, 13 Nov 2003 10:01:57 +0900 (JST) Original-To: stephen@xemacs.org In-reply-to: <87ekwdilwx.fsf@tleepslib.sk.tsukuba.ac.jp> (stephen@xemacs.org) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17787 gmane.mail.mew.general:538 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17787 In article <87ekwdilwx.fsf@tleepslib.sk.tsukuba.ac.jp>, "Stephen J. Turnbull" writes: >>>>>> "Kenichi" == Kenichi Handa writes: >>> 7. The UTF-8 encoding Kenichi> [...] >>> How about using this to encode mule-unicode-0100-24ff? Kenichi> That's a good idea. I'll work on it. > AFAIK this is an XFree86-only extension. As of X11R6.4 such > extensions were forbidden in X.org Compound Text Encoding. Is it > really a good idea? I think so. Currently we encode mule-unicode-0100-24ff by ESC $ - 1 ... which is also an invalid code, and only Emacs can decode it. If we use UTF-8 encoding, more clients can decode it. > On the other hand, even if extended segments are ugly, we must support > extended segments to handle ISO-8859-15 selections on XFree86. At > least it is a standard mechanism on all versions of X, going back to > at least X11R5. Emacs decodes extended segment for ISO-8859-15 correctly, but doesn't use it for encoding. According to Dave, Latin-9 (ISO-8859-15) users don't want it. See this code in mule.el. ;; If you add charsets here, be sure to modify the regexp used by ;; ctext-pre-write-conversion to look up non-standard charsets. (defvar ctext-non-standard-designations-alist '(("$(0" . (big5 "big5-0" 2)) ("$(1" . (big5 "big5-0" 2)) ;; The following are actually standard; generating extended ;; segments for them is wrong and screws e.g. Latin-9 users. ;; 8859-{10,13,16} aren't Emacs charsets anyhow. -- fx ;; ("-V" . (t "iso8859-10" 1)) ;; ("-Y" . (t "iso8859-13" 1)) ;; ("-_" . (t "iso8859-14" 1)) ;; ("-b" . (t "iso8859-15" 1)) ;; ("-f" . (t "iso8859-16" 1)) I think Dave is correct because CTEXT spec has this paragraph. Extended segments are not to be used for any character set encoding that can be constructed from a GL/GR pair of approved standard encodings. For example, it is incorrect to use an extended segment for any of the ISO 8859 family of encodings. --- Ken'ichi HANDA handa@m17n.org