Re: MML charset tag regression

[Kenichi Handa <handa@m17n.org>]

In article <2950-Sun25May2003202510+0300-eliz@elta.co.il>, "Eli Zaretskii" <eliz@elta.co.il> writes:
>>  From: Dave Love <d.love@dl.ac.uk> 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