Merge from emacs-23
[bpt/emacs.git] / doc / lispref / loading.texi
index bbdd67f..05d8361 100644 (file)
@@ -107,6 +107,10 @@ in @code{load-path}, where @code{nil} stands for the default directory.
 @code{load-path}, then all three suffixes in the second directory, and
 so on.  @xref{Library Search}.
 
+Whatever the name under which the file is eventually found, and the
+directory where Emacs found it, Emacs sets the value of the variable
+@code{load-file-name} to that file's name.
+
 If you get a warning that @file{foo.elc} is older than @file{foo.el}, it
 means you should consider recompiling @file{foo.el}.  @xref{Byte
 Compilation}.
@@ -157,6 +161,12 @@ This variable is non-@code{nil} if Emacs is in the process of loading a
 file, and it is @code{nil} otherwise.
 @end defvar
 
+@defvar load-file-name
+When Emacs is in the process of loading a file, this variable's value
+is the name of that file, as Emacs found it during the search
+described earlier in this section.
+@end defvar
+
 @defvar load-read-function
 @anchor{Definition of load-read-function}
 @c do not allow page break at anchor; work around Texinfo deficiency.
@@ -367,13 +377,6 @@ example) is read without decoding, the text of the program will be
 unibyte text, and its string constants will be unibyte strings.
 @xref{Coding Systems}.
 
-  To make the results more predictable, Emacs always performs decoding
-into the multibyte representation when loading Lisp files, even if it
-was started with the @samp{--unibyte} option.  This means that string
-constants with non-@acronym{ASCII} characters translate into multibyte
-strings.  The only exception is when a particular file specifies no
-decoding.
-
   The reason Emacs is designed this way is so that Lisp programs give
 predictable results, regardless of how Emacs was started.  In addition,
 this enables programs that depend on using multibyte text to work even