*** empty log message ***

etc/ChangeLog

+2000-10-16  Gerd Moellmann  <gerd@gnu.org>
+
+	* 3B-MAXMEM, AIX.DUMP, SUN-SUPPORT: Removed.
+
+	* tasks.texi: Updated to the version from /gd/gnuorg.
+
 2000-10-13  John Wiegley  <johnw@gnu.org>
 
 	* NEWS: Added a note about Eshell.

etc/DEBUG

 Debugging GNU Emacs
-Copyright (c) 1985 Richard M. Stallman.
+Copyright (c) 1985, 2000 Free Software Foundation, Inc.
 
    Permission is granted to anyone to make or distribute verbatim copies
    of this document as received, in any medium, provided that the
@@ -12,23 +12,6 @@ Copyright (c) 1985 Richard M. Stallman.
    under the above conditions, provided also that they
    carry prominent notices stating who last changed them.
 
-On 4.2 you will probably find that dbx does not work for
-debugging GNU Emacs.  For one thing, dbx does not keep the
-inferior process's terminal modes separate from its own.
-For another, dbx does not put the inferior in a separate
-process group, which makes trouble when an inferior uses
-interrupt input, which GNU Emacs must do on 4.2.
-
-dbx has also been observed to have other problems,
-such as getting incorrect values for register variables
-in stack frames other than the innermost one.
-
-The Emacs distribution now contains GDB, the new source-level
-debugger for the GNU system.  GDB works for debugging Emacs.
-GDB currently runs on vaxes under 4.2 and on Sun 2 and Sun 3
-systems.
-
-
 ** Some useful techniques
 
 `Fsignal' is a very useful place to stop in.
@@ -50,21 +33,9 @@ to get an opportunity to do the set command.
 
 If you are using cbreak input (see the Lisp function set-input-mode),
 then typing Control-g will cause a SIGINT, which will return control
-to the debugger immediately unless you have done
-
-    ignore 3  (in dbx)
-or  handle 3 nostop noprint  (in gdb)
-
-You will note that most of GNU Emacs is written to avoid
-declaring a local variable in an inner block, even in
-cases where using one would be the cleanest thing to do.
-This is because dbx cannot access any of the variables
-in a function which has even one variable defined in an
-inner block.  A few functions in GNU Emacs do have variables
-in inner blocks, only because I wrote them before realizing
-that dbx had this problem and never rewrote them to avoid it.
+to GDB immediately if you type this command first:
 
-I believe that GDB does not have such a problem.
+    handle 2 stop
 
 
 ** Examining Lisp object values.

lispref/nonascii.texi

@@ -60,10 +60,10 @@ character are always in the range 160 through 255 (octal 0240 through
 0377); these values are @dfn{trailing codes}.
 
   Some sequences of bytes are not valid in multibyte text: for example,
-a single isolated byte in the range 128 through 159 is not allowed.
-But character codes 128 through 159 can appear in multibyte text,
-represented as two-byte sequences.  None of the character codes 128
-through 255 normally appear in ordinary multibyte text, but they do
+a single isolated byte in the range 128 through 159 is not allowed.  But
+character codes 128 through 159 can appear in multibyte text,
+represented as two-byte sequences.  All the character codes 128 through
+255 are possible (though slightly abnormal) in multibyte text; they
 appear in multibyte buffers and strings when you do explicit encoding
 and decoding (@pxref{Explicit Encoding}).
 
@@ -135,15 +135,15 @@ acceptable because the buffer's representation is a choice made by the
 user that cannot be overridden automatically.
 
   Converting unibyte text to multibyte text leaves @sc{ascii} characters
-unchanged, and likewise 128 through 159.  It converts the non-@sc{ascii}
-codes 160 through 255 by adding the value @code{nonascii-insert-offset}
-to each character code.  By setting this variable, you specify which
-character set the unibyte characters correspond to (@pxref{Character
-Sets}).  For example, if @code{nonascii-insert-offset} is 2048, which is
-@code{(- (make-char 'latin-iso8859-1) 128)}, then the unibyte
-non-@sc{ascii} characters correspond to Latin 1.  If it is 2688, which
-is @code{(- (make-char 'greek-iso8859-7) 128)}, then they correspond to
-Greek letters.
+unchanged, and likewise character codes 128 through 159.  It converts
+the non-@sc{ascii} codes 160 through 255 by adding the value
+@code{nonascii-insert-offset} to each character code.  By setting this
+variable, you specify which character set the unibyte characters
+correspond to (@pxref{Character Sets}).  For example, if
+@code{nonascii-insert-offset} is 2048, which is @code{(- (make-char
+'latin-iso8859-1) 128)}, then the unibyte non-@sc{ascii} characters
+correspond to Latin 1.  If it is 2688, which is @code{(- (make-char
+'greek-iso8859-7) 128)}, then they correspond to Greek letters.
 
   Converting multibyte text to unibyte is simpler: it discards all but
 the low 8 bits of each character code.  If @code{nonascii-insert-offset}
@@ -242,10 +242,10 @@ codes.  The valid character codes for unibyte representation range from
 0 to 255---the values that can fit in one byte.  The valid character
 codes for multibyte representation range from 0 to 524287, but not all
 values in that range are valid.  The values 128 through 255 are not
-really proper in multibyte text, but they can occur if you do explicit
+entirely proper in multibyte text, but they can occur if you do explicit
 encoding and decoding (@pxref{Explicit Encoding}).  Some other character
 codes cannot occur at all in multibyte text.  Only the @sc{ascii} codes
-0 through 127 are truly legitimate in both representations.
+0 through 127 are completely legitimate in both representations.
 
 @defun char-valid-p charcode &optional genericp
 This returns @code{t} if @var{charcode} is valid for either one of the two