diff options
author | Eli Zaretskii <eliz@gnu.org> | 2000-12-01 15:47:46 +0000 |
---|---|---|
committer | Eli Zaretskii <eliz@gnu.org> | 2000-12-01 15:47:46 +0000 |
commit | a8934bbb895667f4365d8c858593f6659a57ddbf (patch) | |
tree | 5dd4f467ecf59c2229dbb5bee112fdfdf2f61e1c /etc | |
parent | 297efb495ef84ac1084ca6b60c49dfb7c8ab0a03 (diff) | |
download | emacs-a8934bbb895667f4365d8c858593f6659a57ddbf.tar.gz |
Explain why `no-conversion' is no longer appropriate for reading
files with MULE internal representation, such as auto-save files.
Diffstat (limited to 'etc')
-rw-r--r-- | etc/NEWS | 17 |
1 files changed, 17 insertions, 0 deletions
@@ -2002,6 +2002,23 @@ make a difference to some code. ** 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.) |