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
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.
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.
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}).
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}
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
projects / emacs.git / commitdiff