![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
"BG" == Ben Gertzfield <che@debian.org> writes:
BG> I used MULE and xemacs (with Gnus) for years to read my email, BG> but I was never able to find a solution for UTF-8 headers. If BG> you do end up finding one, please let the list know ;) Well, I spent a little time playing with un-define, and googling around, but wasn't able to come up with the magic incantations. Maybe this XEmacs FAQ entry sheds light that we have a while to wait yet... but-thanks-for-the-tips-ly y'rs, -Barry -------------------- snip snip -------------------- File: xemacs-faq.info, Node: Q1.3.9, Next: Q1.4.1, Prev: Q1.3.8, Up: Introduction Q1.3.9: How does XEmacs display Unicode? ---------------------------------------- Mule doesn't have a Unicode charset internally, so there's nothing to bind a Unicode registry to. It would not be straightforward to create, either, because Unicode is not ISO 2022-compatible. You'd have to translate it to multiple 96x96 pages. This means that Mule-UCS uses ordinary national fonts for display. This is not really a problem, except for those languages that use the Unified Han characters. The problem here is that Mule-UCS maps from Unicode code points to national character sets in a deterministic way. By default, this means that Japanese fonts are tried first, then Chinese, then Korean. To change the priority ordering, use the command `un-define-change-charset-order'. It also means you can't use Unicode fonts directly, at least not without extreme hackery. You can run -nw with (set-terminal-coding-system 'utf-8) if you really want a Unicode font for some reason. Real Unicode support will be introduced in XEmacs 22.0.