--- gforth/doc/gforth.ds	2003/03/22 10:04:08	1.116
+++ gforth/doc/gforth.ds	2003/05/04 08:28:28	1.117
@@ -1515,7 +1515,7 @@ You should put a correct stack effect on
 just @code{( -- )}.  You should also add some descriptive comment to
 more complicated words (I usually do this in the lines following
 @code{:}).  If you don't do this, your code becomes unreadable (because
-you have to work through every definition before you can undertsand
+you have to work through every definition before you can understand
 any).
 
 @assignment
@@ -1673,7 +1673,7 @@ In other languages you can use an arbitr
 function; and since there is only one result, you don't have to deal with
 the order of results, either.
 
-In Forth (and other stack-based languages, e.g., Postscript) the
+In Forth (and other stack-based languages, e.g., PostScript) the
 parameter and result order of a definition is important and should be
 designed well.  The general guideline is to design the stack effect such
 that the word is simple to use in most cases, even if that complicates
@@ -12211,11 +12211,10 @@ operating systems. Hopefully, Unicode wi
 @item conditions under which control characters match a space delimiter:
 @cindex space delimiters
 @cindex control characters as delimiters
-If @code{WORD} is called with the space character as a delimiter, all
+If @code{word} is called with the space character as a delimiter, all
 white-space characters (as identified by the C macro @code{isspace()})
-are delimiters. @code{PARSE}, on the other hand, treats space like other
-delimiters. @code{SWORD} treats space like @code{WORD}, but behaves
-like @code{PARSE} otherwise. @code{Name}, which is used by the outer
+are delimiters. @code{Parse}, on the other hand, treats space like other
+delimiters.  @code{Parse-word}, which is used by the outer
 interpreter (aka text interpreter) by default, treats all white-space
 characters as delimiters.