Re: MML charset tag regression

[Kenichi Handa <handa@m17n.org>]

In article <0F223D16-8C72-11D7-8F50-00039363E640@swipnet.se>, "Jan D." <jan.h.d@swipnet.se> writes:
>>  The current Emacs still don't unify Unicode and the other
>>  legacy charsets (e.g. iso-8859-2, jisx0208, gb2312)
>>  automatically.  So, for instance, if iso-8859-2 characters
>>  arrive at Emacs with UTF8_STRING, they are decoded into the
>>  charset mule-unicode-0100-24ff and treated differently
>>  (e.g. in searching) than the characters of the charset
>>  iso-8859-2.

> Okay, that explains it.  But playing the devils advocate a
> bit, does this not simply point out a problem with Emacs,
> not GTK?

It's surely Emacs' problem that the same iso-8859-2
character is represented in two ways internally.  But,
incomplete support of COMPOUND_TEXT is GTK's (or some other
X client's) problem.  As far as they react upon the request
of COMPOUND_TEXT, it should send the correct data (without
cutting off unsupported characters or replacing them with
'?' silenty).  Otherwise, it shouldn't react upon that
request.

> If UTF8_STRING is the recommended thing to use,
> changing GTK would not help much, as there are other X
> toolkits out there (Qt, Motif, and so on), that will start
> to use UTF8_STRING also (Qt already does)?  Isn't this an
> argument for getting the Unicode Emacs branch released, or
> unify charsets?

Of course, with Emacs-unicode, there's no such problem, and
I want to release it as soon as possible.

---
Ken'ichi HANDA
handa@m17n.org