Re: Choice of fonts displaying etc/HELLO

[Eli Zaretskii <eliz@gnu.org>]

> From: Kenichi Handa <handa@m17n.org>
> CC: jasonr@gnu.org, lekktu@gmail.com, emacs-devel@gnu.org
> Date: Tue, 05 Aug 2008 16:33:06 +0900
> 
> In article <uvdykn8rl.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> 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
something.

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