Re: why has mule gone all verbose?

sb> IIRC the XFree86 default is to define X_LOCALE if building sb> against Linux libc5, and to not define it when building sb> against GNU libc 2. GNU libc 2.0 does not support Asian sb> locales, but GNU libc 2.1 reportedly does, though I haven't sb> tested it yet. I'm not sure I understand the ins and outs of Andy's problem, but on the Linux side this is a FAQ here in Japan. The problem is as you say that XFree86 made a policy decision to disable the X11 locale code. Since there are no Asian locales in glibc 2.0, this made many many people unhappy. The usual solution was to downgrade to an older X11. Most Japanese-capable Linux distributions (Debian-JP and TurboLinux) have been using a dual libc5/libc6 solution (most apps are linked with glibc-2 but the X11 libraries are linked against Linux libc5, yuck) until very recently. I guess Norman's startup is quiet because RedHat 5.1 supports at least the default C locale. Although it seems that he got the "doesn't even support locale `C'" warning, which I don't understand; the fallback to an attempt to set locale to C happens on all paths that attempt to initialize XIM, and I believe that always happens in an XIM-enabled XEmacs. I assume that Cygwin doesn't support POSIX locales yet? Or Andy doesn't have a collection of locale data? Or Cygwin's glibc support doesn't hook to the locale data or something? I haven't heard anything about the Asian locale support in libc 2.1. On the list of projects for January.... -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."