Re: Latin 9 characters cropping up from XKB usage

Hrvoje> I've just tracked it down using `load-history': it got Hrvoje> loaded when I loaded `un-define' to deal with a UTF-8 news Hrvoje> article in Gnus (those are getting more and more common). Hrvoje> It loaded `latin-euro-standards', which in turn loaded Hrvoje> `latin-euro-latin9'. Ah, that makes some sense. I suspect that's the only way to get a Euro sign currently. So we should be able to defeat the bad side effect by assigning those characters to Latin 2 at startup time. I guess the hack would be to have a latin-input-priority variable. This would contain a list of Latin charset symbols. The default would be <x11/keysymdef.h> order, giving the result that makes sense in the case in point. Users with different needs could change it. But I'm confused. Suppose you want to use a SHARP S or some other letter, which is common to ISO 8859/1 and ISO 8859/2. Surely that's a reasonable thing for you to do. But it gets assigned the charset latin-iso8859-1 (which is wrong for you), doesn't it? Don't you perceive that as breakage too? Hrvoje> Maybe it's normal in Japan, but people don't expect such Hrvoje> breakage here. Maybe we've been spoiled by Microsoft or Hrvoje> something. I didn't exactly say I expect it, just that I've always gotten it. Be that as it may, keyboard misbehavior is a FAQ on XEmacs Beta, and often it is from Europeans. Hrvoje> š and ž belong to (at least) *two* standard-compliant Hrvoje> charsets, and given Mule's design, we must choose one. I Hrvoje> was proposing to choose one whose users actually need Hrvoje> those characters. We have to choose at some point, but not at library-writing time! At the very least, let's wait until initialization. :-) -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.