# HG changeset patch # User Eli Zaretskii # Date 975685666 0 # Node ID 4fcc3c4e9b0f4c65a21a7e7fc4dc64cdcdb3533b # Parent 2230e1d249aaeb16d87df1a9db14fae50f11c256 Explain why `no-conversion' is no longer appropriate for reading files with MULE internal representation, such as auto-save files. diff -r 2230e1d249aa -r 4fcc3c4e9b0f etc/NEWS --- a/etc/NEWS Fri Dec 01 15:30:43 2000 +0000 +++ b/etc/NEWS Fri Dec 01 15:47:46 2000 +0000 @@ -2002,6 +2002,23 @@ ** The new treatment of the minibuffer prompt might affect code which operates on the minibuffer. +** The new character sets `eight-bit-control' and `eight-bit-graphic' +cause `no-conversion' and `emacs-mule-unix' coding systems to produce +different results when reading files with non-ASCII characters +(previously, both coding systems would produce the same results). +Specifically, `no-conversion' interprets each 8-bit byte as a separate +character. This makes `no-conversion' inappropriate for reading +multibyte text, e.g. buffers written to disk in their internal MULE +encoding (auto-saving does that, for example). If a Lisp program +reads such files with `no-conversion', each byte of the multibyte +sequence, including the MULE leading codes such as \201, is treated as +a separate character, which prevents them from being interpreted in +the buffer as multibyte characters. + +Therefore, Lisp programs that read files which contain the internal +MULE encoding should use `emacs-mule-unix'. `no-conversion' is only +appropriate for reading truly binary files. + * Lisp changes made after edition 2.6 of the Emacs Lisp Manual, (Display-related features are described in a page of their own below.)