I'm not yet putting in a formal bug report, as I still have ambitions to sort it out myself, but I'd like to mention the problem in case somebody else already knows about it, or can guess the likely location of the problem. I use 21.4.20, with mule-ucs handling unicode. My packages are the most recent sumos. Since I'm usually dealing with old-ish Chinese, I want to (un-define-change-charset-order '(ascii chinese-big5-1 chinese-big5-2)) so that I get big5 characters whenever possible, rather than the default Japanese. Unfortunately, there is a bug in the conversion from UCS to Big5: a UCS codepoint that is found to be in the chinese-big5-2 charset is mistranslated into an Emacs character. Depending on the precise character, this may simply result in corruption, or it may result in a crash. For example, create a file containing the single character U+8F46 (corresponding to Big5 F146) in the UTF-8 encoding. Do the above change of charset ordering, and visit the file in utf-8. XEmacs crashes with a segfault inside buffer_insert_string_1 at insdel.c:359. (That's with a standard build; with a build without optimization (just -g), it goes into an infinite loop instead.) The problem seems to be specific to chinese-big5-2 : if I prioritize the CNS character sets instead, it's fine - but unfortunately my big5 fonts are better than my CNS fonts, so I prefer big5, and anyway I want to save big5 versions in parallel with utf-8 versions. Since the translation process is an unholy mess of semi-automatically generated CCL programs, it's, erm, challenging to debug. If anybody has any private notes about how it all fits together, I'd appreciate any hints! _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta