SL Baur <steve(a)xemacs.org> writes:
> Hrvoje Niksic <hniksic(a)srce.hr> writes:
>
> > Obviously, something gets corrupted in Mule when XEmacs tries to
> > emulate the losing FSF \H-foo syntax. Try commenting out `#define
> > FSF_KEYS' at lread.c:1596 and recompiling XEmacs. See if the bug
> > repeats.
>
> (read-kbd-macro "\H-a")
> => [(hyper ?a)]
>
> (read-kbd-macro "\s-a")
> => [(super ?a)]
>
> *Much* better.
Yup. "\H-a" is equivalent to "H-a", which gets processed correctly by
`read-kbd-macro'.
> > I think we should murder the FSF_KEYS "emulation" that causes nothing
> > but trouble, and serves no good.
>
> I've killed it for the Mule in beta38. What do the FSF keys do in
> non-Mule?
Nothing, as far as I can tell. ?\H-a evaluates to ?a. The code is
*supposed* to produce some weird constants, to make some sense out of
FSF bytecode. In XEmacs 19 it worked because characters were integers
(someone should check what ?\H-a evaluates to in XEmacs 19). In
XEmacs 20/no-mule these "big" chars get trimmed to a byte and we don't
notice the ebolification. In XEmacs 20/Mule the "big" chars get
turned into illegal Emchars and we get a crash.
I think we should disable FSF keys unconditionally, for consistency,
with an explanatory comment.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Manic depression is cool... your body can make its own drugs."