I posted this to xemacs(a)xemacs.org, but I'm not sure whether that was
really the right place. Apologies to those seeing this again.
Currently (as of the latest beta), in XEmacs/MULE the control-1
charset has the graphic property 0. This means that when a control-1
character is displayed, as can happen when viewing files that don't
know about MULE and expect to be using a font with glyphs in the
control-1 range, they are incorrectly displayed. Control-1 character
n, which corresponds to character 128+n in an 8-bit environment, is
displayed as glyph n, instead of 128+n.
I claim that this is a bug, and that the control-1 charset should have
the graphic property 1, so that it displays in the expected place.
Comments?
I suggest the following patch to mule-charset.c
--- mule-charset.c.dist Thu Oct 22 13:42:23 1998
+++ mule-charset.c Thu Oct 22 13:42:58 1998
@@ -1249,7 +1249,7 @@
build_string ("iso8859-1"));
Vcharset_control_1 =
make_charset (-1, Qcontrol_1, LEADING_BYTE_CONTROL_1, 2,
- CHARSET_TYPE_94, 1, 0, 0,
+ CHARSET_TYPE_94, 1, 1, 0,
CHARSET_LEFT_TO_RIGHT,
build_string ("Control characters"),
build_string (""));