--- a/man/ChangeLog	Sat Jun 18 21:51:07 2005 +0000
+++ b/man/ChangeLog	Sun Jun 19 20:49:47 2005 +0000
@@ -1,3 +1,12 @@
+2005-06-19  Aidan Kehoe  <kehoea@parhasard.net>
+
+	* lispref/building.texi (Building XEmacs and Object Allocation):
+	Pure storage has been gone for half a decade or more. 
+	* lispref/mule.texi (Internationalization Terminology): 
+	Phrase stuff a little more clearly, compare Mule with Unicode. 
+	* lispref/lispref.texi (Top):
+	Take out info on pure storage. 
+
 2005-05-28  Stephen J. Turnbull  <stephen@xemacs.org>
 
 	* XEmacs 21.5.21 "corn" is released.

--- a/man/lispref/building.texi	Sat Jun 18 21:51:07 2005 +0000
+++ b/man/lispref/building.texi	Sun Jun 19 20:49:47 2005 +0000
@@ -17,7 +17,6 @@
 
 @menu
 * Building XEmacs::     How to preload Lisp libraries into XEmacs.
-* Pure Storage::        A kludge to make preloaded Lisp functions sharable.
 * Garbage Collection::  Reclaiming space for Lisp objects no longer used.
 @end menu
 
@@ -34,9 +33,8 @@
   The @cite{XEmacs Internals Manual} contains more information about this.
 
   Compilation of the C source files in the @file{src} directory
-produces an executable file called @file{temacs}, also called a
-@dfn{bare impure XEmacs}.  It contains the XEmacs Lisp interpreter and I/O
-routines, but not the editing commands.
+produces an executable file called @file{temacs}.  It contains the
+XEmacs Lisp interpreter and I/O routines, but not the editing commands.
 
 @cindex @file{loadup.el}
   Before XEmacs is actually usable, a number of Lisp files need to be
@@ -80,17 +78,12 @@
 out of luck unless you're able to bootstrap @file{xemacs} from
 @file{temacs}.  Note that @samp{make all-elc} actually loads the
 alternative loadup file @file{loadup-el.el}, which works like
-@file{loadup.el} but disables the pure-copying process and forces
-XEmacs to ignore any compiled Lisp files even if they exist.)
+@file{loadup.el} but forces XEmacs to ignore any compiled Lisp files
+even if they exist.)
 
 @cindex @file{site-load.el}
   You can specify additional files to preload by writing a library named
-@file{site-load.el} that loads them.  You may need to increase the value
-of @code{PURESIZE}, in @file{src/puresize.h}, to make room for the
-additional files.  You should @emph{not} modify this file directly,
-however; instead, use the @samp{--puresize} configuration option. (If
-you run out of pure space while dumping @file{xemacs}, you will be told
-how much pure space you actually will need.) However, the advantage of
+@file{site-load.el} that loads them.  However, the advantage of
 preloading additional files decreases as machines get faster.  On modern
 machines, it is often not advisable, especially if the Lisp code is
 on a file system local to the machine running XEmacs.
@@ -178,61 +171,6 @@
 20.1, the value is 1.
 @end defvar
 
-@node Pure Storage
-@appendixsec Pure Storage
-@cindex pure storage
-
-  XEmacs Lisp uses two kinds of storage for user-created Lisp objects:
-@dfn{normal storage} and @dfn{pure storage}.  Normal storage is where
-all the new data created during an XEmacs session is kept; see the
-following section for information on normal storage.  Pure storage is
-used for certain data in the preloaded standard Lisp files---data that
-should never change during actual use of XEmacs.
-
-  Pure storage is allocated only while @file{temacs} is loading the
-standard preloaded Lisp libraries.  In the file @file{xemacs}, it is
-marked as read-only (on operating systems that permit this), so that the
-memory space can be shared by all the XEmacs jobs running on the machine
-at once.  Pure storage is not expandable; a fixed amount is allocated
-when XEmacs is compiled, and if that is not sufficient for the preloaded
-libraries, @file{temacs} aborts with an error message.  If that happens,
-you must increase the compilation parameter @code{PURESIZE} using the
-@samp{--puresize} option to @file{configure}.  This normally won't
-happen unless you try to preload additional libraries or add features to
-the standard ones.
-
-@defun purecopy object
-This function makes a copy of @var{object} in pure storage and returns
-it.  It copies strings by simply making a new string with the same
-characters in pure storage.  It recursively copies the contents of
-vectors and cons cells.  It does not make copies of other objects such
-as symbols, but just returns them unchanged.  It signals an error if
-asked to copy markers.
-
-This function is a no-op in XEmacs, and its use is deprecated.
-@end defun
-
-@defvar pure-bytes-used
-The value of this variable is the number of bytes of pure storage
-allocated so far.  Typically, in a dumped XEmacs, this number is very
-close to the total amount of pure storage available---if it were not,
-we would preallocate less.
-@end defvar
-
-@defvar purify-flag
-This variable determines whether @code{defun} should make a copy of the
-function definition in pure storage.  If it is non-@code{nil}, then the
-function definition is copied into pure storage.
-
-This flag is @code{t} while loading all of the basic functions for
-building XEmacs initially (allowing those functions to be sharable and
-non-collectible).  Dumping XEmacs as an executable always writes
-@code{nil} in this variable, regardless of the value it actually has
-before and after dumping.
-
-You should not change this flag in a running XEmacs.
-@end defvar
-
 @node Garbage Collection
 @appendixsec Garbage Collection
 @cindex garbage collector

--- a/man/lispref/lispref.texi	Sat Jun 18 21:51:07 2005 +0000
+++ b/man/lispref/lispref.texi	Sun Jun 19 20:49:47 2005 +0000
@@ -1199,7 +1199,6 @@
 Building XEmacs and Object Allocation
 
 * Building XEmacs::         How to preload Lisp libraries into XEmacs.
-* Pure Storage::            A kludge to make preloaded Lisp functions sharable.
 * Garbage Collection::      Reclaiming space for Lisp objects no longer used.
 
 @end menu

--- a/man/lispref/mule.texi	Sat Jun 18 21:51:07 2005 +0000
+++ b/man/lispref/mule.texi	Sun Jun 19 20:49:47 2005 +0000
@@ -141,29 +141,39 @@
   An @dfn{encoding} is a way of numerically representing characters from
 one or more character sets into a stream of like-sized numerical values
 called @dfn{words} -- typically 8-bit bytes, but sometimes 16-bit or
-32-bit quantities.  It's very important to clearly distinguish between
-charsets and encodings.  For a simple charset like ASCII, there is only
-one encoding normally used -- each character is represented by a single
-byte, with the same value as its code point.  For more complicated
-charsets, however, or when a single encoding needs to represent more
-than charset, things are not so obvious.  Unicode version 2, for
-example, is a large charset with thousands of characters, each indexed
-by a 16-bit number, often represented in hex, e.g. 0x05D0 for the Hebrew
-letter "aleph".  One obvious encoding (actually two encodings, depending
-on which of the two possible byte orderings is chosen) simply uses two
-bytes per character.  This encoding is convenient for internal
-processing of Unicode text; however, it's incompatible with ASCII, and
-thus external text (files, e-mail, etc.) that is encoded this way is
-completely uninterpretable by programs lacking Unicode support.  For
-this reason, a different, ASCII-compatible encoding, e.g. UTF-8, is
-usually used for external text.  UTF-8 represents Unicode characters
-with one to three bytes (often extended to six bytes to handle
-characters with up to 31-bit indices).  Unicode characters 00 to 7F
-(identical with ASCII) are directly represented with one byte, and other
-characters with two or more bytes, each in the range 80 to FF.
-Applications that don't understand Unicode will still be able to process
-ASCII characters represented in UTF-8-encoded text, and will typically
-ignore (and hopefully preserve) the high-bit characters.
+32-bit quantities.  In a context where dealing with Japanese motivates
+much of XEmacs' design in this area, it's important to clearly
+distinguish between charsets and encodings.  For a simple charset like
+ASCII, there is only one encoding normally used -- each character is
+represented by a single byte, with the same value as its code point.
+For more complicated charsets, however, or when a single encoding needs
+to represent more than charset, things are not so obvious.  Unicode
+version 2, for example, is a large charset with thousands of characters,
+each indexed by a 16-bit number, often represented in hex, e.g. 0x05D0
+for the Hebrew letter "aleph".  One obvious encoding (actually two
+encodings, depending on which of the two possible byte orderings is
+chosen) simply uses two bytes per character.  This encoding is
+convenient for internal processing of Unicode text; however, it's
+incompatible with ASCII, and thus external text (files, e-mail, etc.) 
+that is encoded this way is completely uninterpretable by programs
+lacking Unicode support.  For this reason, a different, ASCII-compatible
+encoding, e.g. UTF-8, is usually used for external text.  UTF-8
+represents Unicode characters with one to three bytes (often extended to
+six bytes to handle characters with up to 31-bit indices).  Unicode
+characters 00 to 7F (identical with ASCII) are directly represented with
+one byte, and other characters with two or more bytes, each in the range
+80 to FF.  Applications that don't understand Unicode will still be able
+to process ASCII characters represented in UTF-8-encoded text, and will
+typically ignore (and hopefully preserve) the high-bit characters.
+
+Similarly, Shift-JIS and EUC-JP are different encodings normally used to
+encode the same character set(s), these character sets being subsets of
+Unicode.  However, the obvious approach of unifying XEmacs' internal
+encoding across character sets, as was part of the motivation behind
+Unicode, wasn't taken.  This means that characters in these character
+sets that are identical to characters in other character sets---for
+example, the Greek alphabet is in the large Japanese character sets and
+at least one European character set--are unfortunately disjoint. 
 
   Naive use of code points is also not possible if more than one
 character set is to be used in the encoding.  For example, printed