Aidan Kehoe <kehoea(a)parhasard.net> writes:
> 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?]
Of course, and more than once. Since I now use hr_US all the time,
any time I start XEmacs, it is with hr_US already "loaded".
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)
Eek. That is amazingly evil. I don't know why they added š and ž to
Latin 9 in the first place, but hardcoding them to that charset in
XEmacs definitely makes no sense. I vote to remove scaron and zcaron
from that code.
If (featurep 'latin-euro-latin9) or (featurep
'latin-unity-latin9)
is true,
The former is t.
I've elided your text which refers to a workaround ("starting XEmacs
with hr_US already loaded") that doesn't work. I still think it makes
sense not to force scaron and zcaron into Latin 9, where they clearly
don't belong.
Even if it worked, it wouldn't be a good workaround. People *do*
switch keyboards, and switching keyboards can't be expected to break
things.