From 1e4d32f80e868ab417c2acf1002e378b03237d7e Mon Sep 17 00:00:00 2001 From: Gerd Moellmann Date: Mon, 16 Oct 2000 11:43:01 +0000 Subject: [PATCH] *** empty log message *** --- etc/ChangeLog | 6 ++++++ etc/DEBUG | 35 +++-------------------------------- lispref/nonascii.texi | 30 +++++++++++++++--------------- 3 files changed, 24 insertions(+), 47 deletions(-) diff --git a/etc/ChangeLog b/etc/ChangeLog index 7645f002188..46d1b5be54b 100644 --- a/etc/ChangeLog +++ b/etc/ChangeLog @@ -1,3 +1,9 @@ +2000-10-16 Gerd Moellmann + + * 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 --git a/etc/DEBUG b/etc/DEBUG index 045444d11ae..42b965b098f 100644 --- a/etc/DEBUG +++ b/etc/DEBUG @@ -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 @@ 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. diff --git a/lispref/nonascii.texi b/lispref/nonascii.texi index 7452d931354..52330b090fa 100644 --- a/lispref/nonascii.texi +++ b/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 -- 2.39.2