- XEmacs v20 is the version of XEmacs that includes MULE
-(Asian-language) support. XEmacs 20.0 was released in February 1997,
-followed by XEmacs 20.2 in May, XEmacs 20.3 in November and XEmacs 20.4
-in February 1998. When compiled without MULE support, 20.4 is
-approximately as stable as 19.16, and probably faster (due to
-additional optimization work.)
-
- As of XEmacs 20.3, version 20 is _the_ supported version of XEmacs.
-This means that 19.16 will optionally receive stability fixes (if any),
-but that all the real development work will be done on the v20 tree.
-
- The incompatible changes in XEmacs 20 include the additional
-byte-codes, new primitive data types (`character', `char-table', and
-`range-table'). This means that the character-integer equivalence
-inherent to all the previous Emacs and XEmacs releases no longer
-applies.
-
- However, to avoid breaking old code, many functions that should
-normally accept characters work with integers, and vice versa. For more
-information, see the Lisp reference manual. Here is a relevant excerpt,
-for your convenience.
-
- In XEmacs version 19, and in all versions of FSF GNU Emacs, a
- "character" in XEmacs Lisp is nothing more than an integer. This
- is yet another holdover from XEmacs Lisp's derivation from
- vintage-1980 Lisps; modern versions of Lisp consider this
- equivalence a bad idea, and have separate character types. In
- XEmacs version 20, the modern convention is followed, and
- characters are their own primitive types. (This change was
- necessary in order for MULE, i.e. Asian-language, support to be
- correctly implemented.)
-
- Even in XEmacs version 20, remnants of the equivalence between
- characters and integers still exist; this is termed the "char-int
- confoundance disease". In particular, many functions such as `eq',
- `equal', and `memq' have equivalent functions (`old-eq',
- `old-equal', `old-memq', etc.) that pretend like characters are
- integers are the same. Byte code compiled under any version 19
- Emacs will have all such functions mapped to their `old-'
- equivalents when the byte code is read into XEmacs 20. This is to
- preserve compatibility--Emacs 19 converts all constant characters
- to the equivalent integer during byte-compilation, and thus there
- is no other way to preserve byte-code compatibility even if the
- code has specifically been written with the distinction between
- characters and integers in mind.
-
- Every character has an equivalent integer, called the "character
- code". For example, the character `A' is represented as the
- integer 65, following the standard ASCII representation of
- characters. If XEmacs was not compiled with MULE support, the
- range of this integer will always be 0 to 255--eight bits, or one
- byte. (Integers outside this range are accepted but silently
- truncated; however, you should most decidedly _not_ rely on this,
- because it will not work under XEmacs with MULE support.) When
- MULE support is present, the range of character codes is much
- larger. (Currently, 19 bits are used.)
-
- FSF GNU Emacs uses kludgy character codes above 255 to represent
- keyboard input of ASCII characters in combination with certain
- modifiers. XEmacs does not use this (a more general mechanism is
- used that does not distinguish between ASCII keys and other keys),
- so you will never find character codes above 255 in a non-MULE
- XEmacs.
-
- Individual characters are not often used in programs. It is far
- more common to work with _strings_, which are sequences composed of
- characters.