Re: Latin 9 characters cropping up from XKB usage
Ar an seachtú lá déag de mí Méan Fómhair, scríobh Hrvoje Nikšić:
> Stephen’s Latin Unity package assigns the Latin 9 characters as
the
> corresponding keysyms’ mappings, if no mapping exists when it’s
> loaded. To avoid this, and to have your Latin 2 characters inserted
> by default, start XEmacs with the hr_US layout already loaded, and
> the X11 platform code will look at the keysym on the keyboard, note
> that it’s in the Latin 2 range, and assign it the Latin 2 character.
I'm not sure what you mean. For one, I'm not even using latin unity,
so it can't be held responsible for this problem. Then, I don't think
starting XEmacs with hr_US already loaded helps any;
[Have you tried?]
XEmacs is capable of locating "new" keysyms, looking up
their character
values, and binding them to self-insert-command.
Yeah; and if they’re already bound, XEmacs won’t do that.
Cf. this, which used to be in latin-unity, but was factored out to
latin-euro-latin9.el to get Mule-UCS to stop trashing data from some
relevant character sets;
;;;###autoload
(flet ((define-keysym-as-char (keysym character)
(unless (lookup-key global-map (vector keysym))
(define-key global-map (vector keysym) #'self-insert-command))
;; Belt and braces ...
(unless (get-character-of-keysym keysym)
(set-character-of-keysym keysym character)))
(foo (k o)
(define-keysym-as-char k (make-char 'latin-iso8859-15 o))))
(foo 'EuroSign #x24)
(foo 'Scaron #x26)
(foo 'scaron #x28)
(foo 'Zcaron #x34)
(foo 'zcaron #x38)
(foo 'OE #x3C)
(foo 'oe #x3D)
(foo 'Ydiaeresis #x3E))
If (featurep 'latin-euro-latin9) or (featurep 'latin-unity-latin9) is true,
and XEmacs didn’t know about an scaron or zcaron keysym existing on the
server’s keyboards when those files were loaded, then scaron and zcaron will
be bound to the Latin 9 characters by that autoload code. Changing to a
keyboard with scaron or zcaron available won’t change their bindings, which
is the right thing to do in the general case, but bit you in the arse here.
The general solution to this problem is to have a state for X11 keysyms that
says “this keysym is on the keyboard but we haven’t found anything to bind
it to, even though it should bind to a character” As it is, we don’t
differentiate between this case and the “this keysym is on the keyboard
and isn’t bound.” Implementing this general case does not make sense given
the benefit involved and the work necessary. “Start XEmacs with hr_US
already loaded” is an acceptable workaround, given that that’s what you’re
doing anyway.
Also, why do you think the keysym will prove to be "in the Latin
2
range"? What if the keysym turns out to be in the Latin 9 range?
Then the X server is broken, because that character already existed in the
Latin 2 range before the Latin 9 range was introduced, and the specs say
“use the old keysym” in that case.
Of course, lots of X servers _are_ broken, and they may well be broken in
this way. That’s what x-win-init-xfree86 and x-win-init-sun are for, and we
can stick in code there to handle this case if it happens.
š and ž *are* also present in Latin 9.
--
„Frauen achten mehr aufs Herz und weniger auf Dummheiten. Darum leben sie
länger.“ (C.R. Zafón -- Übertragung von Peter Schwaar.)