Re: Coredumping bug in 21 (read-kbd-macro)
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."