I agree with you in many technical points. Yes, I use
non-iso8859-1-supported language everyday (Japanese), we've been
struggling with character problems on computer for years. My
experiences includes editor, e-mail, NetNews, and so on. Acutually,
today I attend a meeting which relates ISO 10646-2 activity. Besides,
we're merging MULE (Multilingual Enhancement) features into
forthcoming Emacs 20 currently. You may know that it supports
multiple character sets, and native encoding. Supports for multiple
character sets and native encoding are necessarily for backward
compatibility and information interchange.
However, I don't care much about internal encoding in the application.
Personally, I think that current implementation of internal character
encoding in Emacs-20 and UTF-8 encoding is similar. The difference is
character encoding in Emacs-20 encodes multiple character sets, while
UTF-8 encodes UCS. How about using UTF-8 scheme for multiple
character sets? IMHO, it's the way to go. My rationale for multiple
character sets is that it's very difficult to collect and maintain
large character set (I don't think Unicode 2.0 is large enough). In
China, there've been projects for defining character set since
thousand years ago...
* * *
As many suggests, here is linux-kernel mailing list where we discuss
the kernel issue.
I don't think the issue of "Unicode or Multiple Character Sets?" is
kernel issue for file system. All that we need is distinguish the
delimiter ('/'), I think. In fact, there is an implementation for
"Multiple Character Sets Pathname" feature in Mule-2.3 (user space!),
althogh it is not included in Emacs-20. It supports pathname in
Japanese, in Chinese, or in your favorite language. Well, you could
imagine "GIF Pathname" encoded in UTF-8 scheme...
Discussion on the console driver which supports multiple character
sets or Unicode, or string representation in the kernel are kernel
issue, IMHO.
I know that there are many problem around here and there, let's
improve in constructive way. I love "running code".
Best Regards,
-- NIIBE Yutaka Mitsubishi Research Institute, Inc.