emacs-devel
[Top][All Lists]
Advanced

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

Re: MML charset tag regression


From: David Kastrup
Subject: Re: MML charset tag regression
Date: 23 May 2003 09:45:06 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Kenichi Handa <address@hidden> writes:

> 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
> request.

Right.  I have found it very annoying to find that I can cut&paste
unicode strings from Emacs to galeon, but get only ? when doing it the
other way round.

> > 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.

What's the state of it?  Am I right in assuming that we would first
be releasing a full-featured 21.4 (or, if really necessary, another
bug fix 21.4 followed by a full 21.5)?  In that case, probably
another bug fix 21.xx series would have to follow, and one would
probably make something like 22.0 the goal for a Unicode Emacs, with
probably some alpha versions before that?

Sorry to be using the "R" word here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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