Re: MML charset tag regression

[Kenichi Handa <handa@m17n.org>]

In article <rzq4r3cdbzq.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:

> "Eli Zaretskii" <eliz@elta.co.il> 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  <fx@gnu.org>

	* 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