From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.gnus.general,gmane.emacs.devel Subject: Re: MML charset tag regression Date: Fri, 30 May 2003 10:23:21 +0100 Sender: ding-owner@lists.math.uh.edu Message-ID: 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 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1054286552 16786 80.91.224.249 (30 May 2003 09:22:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 30 May 2003 09:22:32 +0000 (UTC) Cc: ding@gnus.org, jas@extundo.com, emacs-devel@gnu.org Original-X-From: ding-owner+M1474@lists.math.uh.edu Fri May 30 11:22:26 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 19Lg4w-0004Jr-00 for ; Fri, 30 May 2003 11:21:39 +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 19Lg6s-0002to-00; Fri, 30 May 2003 04:23:38 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19Lg6f-0002tg-00 for ding@lists.math.uh.edu; Fri, 30 May 2003 04:23:25 -0500 Original-Received: (qmail 68019 invoked by alias); 30 May 2003 09:23:25 -0000 Original-Received: (qmail 68014 invoked from network); 30 May 2003 09:23:24 -0000 Original-Received: from albion.dl.ac.uk (148.79.80.39) by sclp3.sclp.com with SMTP; 30 May 2003 09:23:24 -0000 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.36 #1 (Debian)) id 19Lg6b-0003Yo-00; Fri, 30 May 2003 10:23:21 +0100 Original-To: Eli Zaretskii User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:52930 gmane.emacs.devel:14471 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14471 "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, 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. Also, the relevant specification is not ICCCM, it's CTEXT, and it seems difficult to argue the case for other people implementing that spec properly if it looks as though the Emacs version is in ignorance of it. > 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.