From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.gnus.general,gmane.emacs.devel Subject: Re: MML charset tag regression Date: Fri, 30 May 2003 20:36:13 +0900 (JST) Sender: ding-owner@lists.math.uh.edu Message-ID: <200305301136.UAA21513@etlken.m17n.org> References: <0F223D16-8C72-11D7-8F50-00039363E640@swipnet.se> <2950-Sun25May2003202510+0300-eliz@elta.co.il> 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: main.gmane.org 1054294527 11332 80.91.224.249 (30 May 2003 11:35:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 30 May 2003 11:35:27 +0000 (UTC) Cc: eliz@elta.co.il, jas@extundo.com, ding@gnus.org, emacs-devel@gnu.org Original-X-From: ding-owner+M1478@lists.math.uh.edu Fri May 30 13:35:24 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19Li9z-0002vl-00 for ; Fri, 30 May 2003 13:34:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19LiBc-0003Q8-00; Fri, 30 May 2003 06:36:40 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19LiBT-0003Q0-00 for ding@lists.math.uh.edu; Fri, 30 May 2003 06:36:31 -0500 Original-Received: (qmail 74584 invoked by alias); 30 May 2003 11:36:30 -0000 Original-Received: (qmail 74578 invoked from network); 30 May 2003 11:36:30 -0000 Original-Received: from tsukuba.m17n.org (192.47.44.130) by sclp3.sclp.com with SMTP; 30 May 2003 11:36:30 -0000 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 h4UBaFu11621; Fri, 30 May 2003 20:36:15 +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 h4UBaE916253; Fri, 30 May 2003 20:36:14 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id UAA21513; Fri, 30 May 2003 20:36:13 +0900 (JST) Original-To: d.love@dl.ac.uk In-reply-to: (message from Dave Love on Fri, 30 May 2003 10:23:21 +0100) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:52934 gmane.emacs.devel:14480 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14480 In article , Dave Love writes: > "Eli Zaretskii" writes: >> The support for extended segments was implemented as an >> extension of ctext to avoid a thorough rewrite of the >> ctext en/decoder. As you know, the ctext encoder and >> decoder are variants of the iso-2022 en/decoder and are >> handled by the same code (in C). > I don't see what this has to do with what I said. The > ctext coding system needs to support extended segments > because they are part of the specification, The ctext coding system at least should not treat extended segments as a part of "Standard Character Set Encodings". So, I commited a change to coding.c. But, ctext itself doesn't have to support it, i.e., decode it as the sender's intention. It's impossible to know about all possible encoding names that will be used in the extended segment. > not an extension of it as the code either says or implies. > What was implemented is a different coding system, not an > extended version of ctext. Surely it's not. ctext and compound-text-with-extensions encode text differently. But, I don't think compound-text-with-extensions implies an extended version of ctext. The "-with-extensions" part of the name just means "that uses extended segments". Is it a problem? > Also, the relevant specification is not ICCCM, it's CTEXT, Yes. I fixed the comment and the variable. I should have noticed it from the first. >> The general idea of the current implementation (using >> post-read and pre-write conversions) was also suggested >> by Handa-san. > I don't know what that's meant to imply, but I doubt it's > fair to blame him for problems with it. I don't feel like I'm blamed by anyone, am I too unblushing? :-p And, I appreciate Eli's original work because it saved my time when I was extremely busy. I eventually fixed the code, but even for that, the existence of the original work saved lots of my time. By the way, I noticed this change of yours. 2002-09-11 Dave Love * international/mule.el (non-standard-designations-alist) (ctext-pre-write-conversion): Don't generate invalid extended segments for iso8859. I agree with this change. I remeber we had been discussed on it. I'm sorry that I didn't react to it by myself. I've just fixed emacs-unicode by the same way. If one really want to encode iso-8859-X by using an extended segment, he can modify non-standard-designations-alist (now the name is changed to ctext-non-standard-designations-alist). --- Ken'ichi HANDA handa@m17n.org