mirror of
git://git.sv.gnu.org/emacs.git
synced 2026-04-18 12:00:38 -07:00
*** empty log message ***
This commit is contained in:
parent
5e0c8a235d
commit
1e4d32f80e
3 changed files with 24 additions and 47 deletions
|
|
@ -1,3 +1,9 @@
|
|||
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.
|
||||
|
|
|
|||
35
etc/DEBUG
35
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
|
||||
to GDB immediately if you type this command first:
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue