[Top][All Lists]

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

Re: Choice of fonts displaying etc/HELLO

From: Eli Zaretskii
Subject: Re: Choice of fonts displaying etc/HELLO
Date: Tue, 05 Aug 2008 21:12:54 +0300

> From: Kenichi Handa <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> Date: Tue, 05 Aug 2008 16:33:06 +0900
> In article <address@hidden>, Eli Zaretskii <address@hidden> writes:
> > > But is that the right way to categorize them? This character (and others
> > > around it) are not Japanese or Korean characters. They just happen to be
> > > included in those encodings. The same goes for Cyrillic and Greek
> > > characters.
> > I agree with Jason.  I reported a similar curiosity the moment the
> > unicode-2 branch was merged with the trunk.
> We don't define the semantics of "category" clearly.  We can
> think of the category name "Japanese" as "characters
> belonging to one of Japanese character set".  Then that
> character surely have that cateogry.  And, in Emacs 22, that
> kind of definition was surely useful.
> Although, I agree that such kind of definition is not
> appropriate now, I have no good idea about how to improve it
> without breaking backward compatibility.

I think the only meaningful categories are those defined by Unicode.
That is, a block of Cyrillic characters should have the cyrillic
category, the block of Japanese characters should have japanese
category, etc.  The fact that the character is covered by some
ISO-2022 charset is not interesting in Emacs 23, unless I'm missing

What kind of backward compatibility problems could we cause?  Who or
what code depends on these categories?

reply via email to

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