mirror/emacs
1
0
Fork 0
mirror of https://git.savannah.gnu.org/git/emacs.git synced 2024-12-28 10:56:36 +00:00
Code Issues Releases Activity

Explain why `no-conversion' is no longer appropriate for reading

Browse Source 
files with MULE internal representation, such as auto-save files.
This commit is contained in:
Eli Zaretskii 2000-12-01 15:47:46 +00:00
parent 68875f0e7b
commit 7c94ccf681
1 changed files with 17 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
etc/NEWS
View File

@ -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.)