diff lispref/streams.texi @ 21682:90da2489c498

*** empty log message ***

--- a/lispref/streams.texi	Mon Apr 20 17:37:53 1998 +0000
+++ b/lispref/streams.texi	Mon Apr 20 17:43:57 1998 +0000
@@ -103,17 +103,21 @@
 
 @item @var{function}
 @cindex function input stream
-The input characters are generated by @var{function}, one character per
-call.  Normally @var{function} is called with no arguments, and should
-return a character.
+The input characters are generated by @var{function}, which must support
+two kinds of calls:
+
+@itemize @bullet
+@item
+When it is called with no arguments, it should return the next character.
 
-@cindex unreading
-Occasionally @var{function} is called with one argument (always a
-character).  When that happens, @var{function} should save the argument
-and arrange to return it on the next call.  This is called
-@dfn{unreading} the character; it happens when the Lisp reader reads one
-character too many and wants to ``put it back where it came from''.
-In this case, it makes no difference what value @var{function} returns.
+@item
+When it is called with one argument (always a character), @var{function}
+should save the argument and arrange to return it on the next call.
+This is called @dfn{unreading} the character; it happens when the Lisp
+reader reads one character too many and wants to ``put it back where it
+came from''.  In this case, it makes no difference what value
+@var{function} returns.
+@end itemize
 
 @item @code{t}
 @cindex @code{t} input stream
@@ -163,13 +167,6 @@
 Note that the first read skips a space.  Reading skips any amount of
 whitespace preceding the significant text.
 
-  In Emacs 18, reading a symbol discarded the delimiter terminating the
-symbol.  Thus, point would end up at the beginning of @samp{contents}
-rather than after @samp{the}.  The current behavior is superior because
-it correctly handles input such as @samp{bar(foo)}, where the
-open-parenthesis that ends one object is needed as the beginning of
-another object.
-
   Here is an example of reading from a stream that is a marker,
 initially positioned at the beginning of the buffer shown.  The value
 read is the symbol @code{This}.
@@ -296,9 +293,9 @@
 remaining character in the string (i.e., the first one not read).
 
 If @var{start} is supplied, then reading begins at index @var{start} in
-the string (where the first character is at index 0).  If @var{end} is
-also supplied, then reading stops just before that index, as if the rest
-of the string were not there.
+the string (where the first character is at index 0).  If you specify
+@var{end}, then reading is forced to stop just before that index, as if
+the rest of the string were not there.
 
 For example:
 
@@ -381,8 +378,8 @@
 @end table
 
   Many of the valid output streams are also valid as input streams.  The
-difference between input and output streams is therefore mostly one of
-how you use a Lisp object, not a distinction of types of object.
+difference between input and output streams is therefore more a matter
+of how you use a Lisp object, than of different types of object.
 
   Here is an example of a buffer used as an output stream.  Point is
 initially located as shown immediately before the @samp{h} in
@@ -532,18 +529,18 @@
 for full details.  You specify quoting or no quoting by the choice of
 printing function.
 
-  If the text is to be read back into Lisp, then it is best to print
-with quoting characters to avoid ambiguity.  Likewise, if the purpose is
-to describe a Lisp object clearly for a Lisp programmer.  However, if
-the purpose of the output is to look nice for humans, then it is better
-to print without quoting.
+  If the text is to be read back into Lisp, then you should print with
+quoting characters to avoid ambiguity.  Likewise, if the purpose is to
+describe a Lisp object clearly for a Lisp programmer.  However, if the
+purpose of the output is to look nice for humans, then it is usually
+better to print without quoting.
 
-  Printing a self-referent Lisp object requires an infinite amount of
-text.  In certain cases, trying to produce this text leads to a stack
-overflow.  Emacs detects such recursion and prints @samp{#@var{level}}
-instead of recursively printing an object already being printed.  For
-example, here @samp{#0} indicates a recursive reference to the object at
-level 0 of the current print operation:
+  Printing a self-referent Lisp object in the normal way would require
+an infinite amount of text, and could even result in stack overflow.
+Emacs detects such recursion and prints @samp{#@var{level}} instead of
+recursively printing an object already being printed.  For example, here
+@samp{#0} indicates a recursive reference to the object at level 0 of
+the current print operation:
 
 @example
 (setq foo (list nil))
@@ -696,9 +693,9 @@
 are printed as @samp{\n} and formfeeds are printed as @samp{\f}.
 Normally these characters are printed as actual newlines and formfeeds.
 
-This variable affects the print functions @code{prin1} and @code{print},
-as well as everything that uses them.  It does not affect @code{princ}.
-Here is an example using @code{prin1}:
+This variable affects the print functions @code{prin1} and @code{print}
+that print with quoting.  It does not affect @code{princ}.  Here is an
+example using @code{prin1}:
 
 @example
 @group