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 (""));