# HG changeset patch # User Gerd Moellmann # Date 971696581 0 # Node ID 4881cd839f125db5bc4e823f2cee0d8980b2bb3b # Parent fedf4de246a194eee729922e3141e7c7ffb84536 *** empty log message *** diff -r fedf4de246a1 -r 4881cd839f12 etc/ChangeLog --- a/etc/ChangeLog Mon Oct 16 11:40:55 2000 +0000 +++ b/etc/ChangeLog Mon Oct 16 11:43:01 2000 +0000 @@ -2,6 +2,8 @@ * 3B-MAXMEM, AIX.DUMP, SUN-SUPPORT: Removed. + * tasks.texi: Updated to the version from /gd/gnuorg. + 2000-10-13 John Wiegley * NEWS: Added a note about Eshell. diff -r fedf4de246a1 -r 4881cd839f12 etc/DEBUG --- a/etc/DEBUG Mon Oct 16 11:40:55 2000 +0000 +++ b/etc/DEBUG Mon Oct 16 11:43:01 2000 +0000 @@ -1,5 +1,5 @@ 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 @@ 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 @@ 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) +to GDB immediately if you type this command first: -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. - -I believe that GDB does not have such a problem. + handle 2 stop ** Examining Lisp object values. diff -r fedf4de246a1 -r 4881cd839f12 lispref/nonascii.texi --- a/lispref/nonascii.texi Mon Oct 16 11:40:55 2000 +0000 +++ b/lispref/nonascii.texi Mon Oct 16 11:43:01 2000 +0000 @@ -60,10 +60,10 @@ 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 @@ 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 @@ 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