[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MML charset tag regression

From: Kenichi Handa
Subject: Re: MML charset tag regression
Date: Fri, 23 May 2003 10:33:44 +0900 (JST)
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)

In article <address@hidden>, "Jan D." <address@hidden> 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

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]