"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
That file is loaded only on explicit user request (at least,
that's
why I put it in the packages)
But I never requested it.
The bug is that they don't get assigned to Latin 2 characters in
a
Latin 2 locale; let's fix that bug. What more could you reasonably
ask for?
That's entirely fine. I could further argue that those two characters
shouldn't be assigned to Latin 9 at all because they're almost never
used by Latin 9 users (they were missing in Latin 1 and I suspect they
were added for compatibility with Windows-1252). But there's no
reason to insist on that if the above goal is met.
>> If (featurep 'latin-euro-latin9) or (featurep
>> 'latin-unity-latin9) is true,
Hrvoje> The former is t.
How did that happen?
I've just tracked it down using `load-history': it got loaded when I
loaded `un-define' to deal with a UTF-8 news article in Gnus (those
are getting more and more common). It loaded `latin-euro-standards',
which in turn loaded `latin-euro-latin9'.
If we did that behind your back, it's an XEmacs bug; that
support
was designed to be loaded on request by people who need Latin 9
support as their primary environment---little thought has been put
into making it loadable by default, and none in combination with
non-Latin-9 environments.
Yup. That's the bug, then. I certainly didn't load
`latin-euro-latin9' for the kicks of it. :-)
"The X Window System. Live the horror." Switching
keyboards has
always broken things for me.
Maybe it's normal in Japan, but people don't expect such breakage
here. Maybe we've been spoiled by Microsoft or something.
This stuff is a nightmare, and it will only get worse if we
deliberately write code that doesn't conform to the existing
standards.
I never suggested that. š and ž belong to (at least) *two*
standard-compliant charsets, and given Mule's design, we must choose
one. I was proposing to choose one whose users actually need those
characters. I still think it's a reasonable proposal.