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.