aboutsummaryrefslogtreecommitdiffstats
path: root/doc/lispref/loading.texi
diff options
context:
space:
mode:
Diffstat (limited to 'doc/lispref/loading.texi')
-rw-r--r--doc/lispref/loading.texi7
1 files changed, 0 insertions, 7 deletions
diff --git a/doc/lispref/loading.texi b/doc/lispref/loading.texi
index bbdd67fc3a5..dee2a0252eb 100644
--- a/doc/lispref/loading.texi
+++ b/doc/lispref/loading.texi
@@ -367,13 +367,6 @@ example) is read without decoding, the text of the program will be
367unibyte text, and its string constants will be unibyte strings. 367unibyte text, and its string constants will be unibyte strings.
368@xref{Coding Systems}. 368@xref{Coding Systems}.
369 369
370 To make the results more predictable, Emacs always performs decoding
371into the multibyte representation when loading Lisp files, even if it
372was started with the @samp{--unibyte} option. This means that string
373constants with non-@acronym{ASCII} characters translate into multibyte
374strings. The only exception is when a particular file specifies no
375decoding.
376
377 The reason Emacs is designed this way is so that Lisp programs give 370 The reason Emacs is designed this way is so that Lisp programs give
378predictable results, regardless of how Emacs was started. In addition, 371predictable results, regardless of how Emacs was started. In addition,
379this enables programs that depend on using multibyte text to work even 372this enables programs that depend on using multibyte text to work even