Commit 1e4d32f8 authored by Gerd Moellmann's avatar Gerd Moellmann
Browse files

*** empty log message ***

parent 5e0c8a23
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.
......
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.
......
......@@ -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
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment