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 17:39:03 +0900 (JST) Sender: ding-owner@lists.math.uh.edu Message-ID: <200305300839.RAA21255@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 1054283911 7577 80.91.224.249 (30 May 2003 08:38:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 30 May 2003 08:38:31 +0000 (UTC) Cc: d.love@dl.ac.uk, jas@extundo.com, ding@gnus.org, emacs-devel@gnu.org Original-X-From: ding-owner+M1473@lists.math.uh.edu Fri May 30 10:38:29 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 19LfP1-0001xT-00 for ; Fri, 30 May 2003 10:38:19 +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 19LfQE-0002b7-00; Fri, 30 May 2003 03:39:34 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19LfQ5-0002az-00 for ding@lists.math.uh.edu; Fri, 30 May 2003 03:39:25 -0500 Original-Received: (qmail 66170 invoked by alias); 30 May 2003 08:39:24 -0000 Original-Received: (qmail 66165 invoked from network); 30 May 2003 08:39:23 -0000 Original-Received: from tsukuba.m17n.org (192.47.44.130) by sclp3.sclp.com with SMTP; 30 May 2003 08:39:23 -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 h4U8d8u10029; Fri, 30 May 2003 17:39:08 +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 h4U8d4914904; Fri, 30 May 2003 17:39:04 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id RAA21255; Fri, 30 May 2003 17:39:03 +0900 (JST) Original-To: eliz@elta.co.il In-reply-to: <2950-Sun25May2003202510+0300-eliz@elta.co.il> 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:52929 gmane.emacs.devel:14469 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14469 In article <2950-Sun25May2003202510+0300-eliz@elta.co.il>, "Eli Zaretskii" writes: >> From: Dave Love Date: Sun, 25 May 2003 >> 17:38:55 +0100 >> >> the Unicode branch doesn't >> actually deal with compound text properly, because it >> doesn't do extended segments, and the released version is >> at best pretty confused about that and I think not >> correct. (Extended segments are not an extension to >> compound text, they're part of the specification, >> contrary to what the current code says.) > 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). At the time, Handa-san > recommended not to touch the iso-2022 code, saying that > the code was tricky and hard to maintain, and that we > could inadvertently break something important in the > process. I've found that at least we must modify iso-2022 decoder so that it retains ctext extended segements. Otherwise, we can't handle this kind of sequence: ESC $ A --GB-SEQ-- ESC % / --EX-SEGENT-- --GB-SEQ-- ESC ( B Please note that the first ESC $ A must take effect also on the second GB-SEQ. So, I've just installed a change in coding.c in addition to the changes in mule.el to utilize the codinc.c change and to rename variables property (ICCCM is not relevant to the spec of CTEXT). I've also installed the similar change in unicode branch. --- Ken'ichi HANDA handa@m17n.org