+@noindent
+and
+
+@smallexample
+"/usr/local/share/emacs/site-lisp"
+@end smallexample
+
+@noindent
+The first one is for locally installed packages for a particular Emacs
+version; the second is for locally installed packages meant for use with
+all installed Emacs versions.
+
+ There are several reasons why a Lisp package that works well in one
+Emacs version can cause trouble in another. Sometimes packages need
+updating for incompatible changes in Emacs; sometimes they depend on
+undocumented internal Emacs data that can change without notice;
+sometimes a newer Emacs version incorporates a version of the package,
+and should be used only with that version.
+
+ Emacs finds these directories' subdirectories and adds them to
+@code{load-path} when it starts up. Both immediate subdirectories and
+subdirectories multiple levels down are added to @code{load-path}.
+
+ Not all subdirectories are included, though. Subdirectories whose
+names do not start with a letter or digit are excluded. Subdirectories
+named @file{RCS} or @file{CVS} are excluded. Also, a subdirectory which
+contains a file named @file{.nosearch} is excluded. You can use these
+methods to prevent certain subdirectories of the @file{site-lisp}
+directories from being searched.
+
+ If you run Emacs from the directory where it was built---that is, an
+executable that has not been formally installed---then @code{load-path}
+normally contains two additional directories. These are the @code{lisp}
+and @code{site-lisp} subdirectories of the main build directory. (Both
+are represented as absolute file names.)
+
+@deffn Command locate-library library &optional nosuffix path interactive-call
+This command finds the precise file name for library @var{library}. It
+searches for the library in the same way @code{load} does, and the
+argument @var{nosuffix} has the same meaning as in @code{load}: don't
+add suffixes @samp{.elc} or @samp{.el} to the specified name
+@var{library}.
+
+If the @var{path} is non-@code{nil}, that list of directories is used
+instead of @code{load-path}.
+
+When @code{locate-library} is called from a program, it returns the file
+name as a string. When the user runs @code{locate-library}
+interactively, the argument @var{interactive-call} is @code{t}, and this
+tells @code{locate-library} to display the file name in the echo area.
+@end deffn
+
+@node Loading Non-ASCII
+@section Loading Non-@sc{ascii} Characters
+
+ When Emacs Lisp programs contain string constants with non-@sc{ascii}
+characters, these can be represented within Emacs either as unibyte
+strings or as multibyte strings (@pxref{Text Representations}). Which
+representation is used depends on how the file is read into Emacs. If
+it is read with decoding into multibyte representation, the text of the
+Lisp program will be multibyte text, and its string constants will be
+multibyte strings. If a file containing Latin-1 characters (for
+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-@sc{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
+in a unibyte Emacs. Of course, such programs should be designed to
+notice whether the user prefers unibyte or multibyte text, by checking
+@code{default-enable-multibyte-characters}, and convert representations
+appropriately.
+
+ In most Emacs Lisp programs, the fact that non-@sc{ascii} strings are
+multibyte strings should not be noticeable, since inserting them in
+unibyte buffers converts them to unibyte automatically. However, if
+this does make a difference, you can force a particular Lisp file to be
+interpreted as unibyte by writing @samp{-*-unibyte: t;-*-} in a
+comment on the file's first line. With that designator, the file will
+unconditionally be interpreted as unibyte, even in an ordinary
+multibyte Emacs session. This can matter when making keybindings to
+non-@sc{ascii} characters written as @code{?v@var{literal}}.