• Download
• XEmacs in GSoC
• FAQ
• Mailing lists
• Documentation
• People
• How to help
• Bugs
• Links

• Mailing lists
• Status of Services
• Near Future
• History of XEmacs
• XEmacs vs. GNU Emacs
• Screenshots
• Sites Created With XEmacs
• Year 2000 Statement
• Who Wrote XEmacs?
• XEmacs Contributors
• Website

• Download
• Optional Libraries
• Installation HOWTOs
• Quickstart Package Guide
• Documentation
• Installation resources
• Releases

• XEmacs Packages
• Other Interesting Sites
• Customization Links

• FAQ
• Reporting Bugs
• Troubleshooting resources
• Debugging

• How to help
• XEmacs in GSoC
• Open Issues
• Who Wrote XEmacs?
• XEmacs Contributors
• Dev team responsibilities
• Architecting XEmacs

Unicode internal encoding

Stephen J. Turnbull <stephen@xemacs.org>

The traditional Mule leading byte representation leads to a number of problems. It conceals difficulties in the implementation of display and I/O streams because the internal representation is very close to the ISO 2022 family, the most common external coding system. (ISO 2022 can be considered a superset of ISO 8859, and is used by most multibyte encodings, e.g. for East Asian languages, as well.) It also tends to lead to bugs in autosave files and so on. A Unicode internal representation would alleviate both of these, and be directly interchangeable with many external programs as well. ``UTF-2000'' refers to the implementation developed by Tomohiko Morioka, likely to be a source of much code.

Status

UTF-2000 (Unicode as internal encoding). I've been puttering away at this, but as maintained by Morioka, it's a moving target and a research vehicle, not a production design. Not ready for prime time.

Open bugs

None.

Other open issues

None.

Discussion

None.

Closed bugs

None.