[Emacs-diffs] Changes to emacs/man/building.texi [gnus-5_10-branch]

[Miles Bader]

Index: emacs/man/building.texi
diff -c /dev/null emacs/man/building.texi:1.37.2.1
*** /dev/null   Sat Sep  4 12:02:50 2004
--- emacs/man/building.texi     Sat Sep  4 12:01:14 2004
***************
*** 0 ****
--- 1,1118 ----
+ @c This is part of the Emacs manual.
+ @c Copyright (C) 1985,86,87,93,94,95,97,2000,2001 Free Software Foundation, 
Inc.
+ @c See file emacs.texi for copying conditions.
+ @node Building, Maintaining, Programs, Top
+ @chapter Compiling and Testing Programs
+ @cindex building programs
+ @cindex program building
+ @cindex running Lisp functions
+ 
+   The previous chapter discusses the Emacs commands that are useful for
+ making changes in programs.  This chapter deals with commands that assist
+ in the larger process of developing and maintaining programs.
+ 
+ @menu
+ * Compilation::         Compiling programs in languages other
+                           than Lisp (C, Pascal, etc.).
+ * Grep Searching::      Running grep as if it were a compiler.
+ * Compilation Mode::    The mode for visiting compiler errors.
+ * Compilation Shell::   Customizing your shell properly
+                           for use in the compilation buffer.
+ * Debuggers::         Running symbolic debuggers for non-Lisp programs.
+ * Executing Lisp::      Various modes for editing Lisp programs,
+                           with different facilities for running
+                           the Lisp programs.
+ * Libraries: Lisp Libraries.      Creating Lisp programs to run in Emacs.
+ * Eval: Lisp Eval.      Executing a single Lisp expression in Emacs.
+ * Interaction: Lisp Interaction.  Executing Lisp in an Emacs buffer.
+ * External Lisp::         Communicating through Emacs with a separate Lisp.
+ @end menu
+ 
+ @node Compilation
+ @section Running Compilations under Emacs
+ @cindex inferior process
+ @cindex make
+ @cindex compilation errors
+ @cindex error log
+ 
+   Emacs can run compilers for noninteractive languages such as C and
+ Fortran as inferior processes, feeding the error log into an Emacs buffer.
+ It can also parse the error messages and show you the source lines where
+ compilation errors occurred.
+ 
+ @table @kbd
+ @item M-x compile
+ Run a compiler asynchronously under Emacs, with error messages going to
+ the @samp{*compilation*} buffer.
+ @item M-x recompile
+ Invoke a compiler with the same command as in the last invocation of
+ @kbd{M-x compile}.
+ @item M-x grep
+ Run @code{grep} asynchronously under Emacs, with matching lines
+ listed in the buffer named @samp{*grep*}.
+ @item M-x grep-find
+ Run @code{grep} via @code{find}, with user-specified arguments, and
+ collect output in the buffer named @samp{*grep*}.
+ @item M-x kill-compilation
+ @itemx M-x kill-grep
+ Kill the running compilation or @code{grep} subprocess.
+ @end table
+ 
+ @findex compile
+   To run @code{make} or another compilation command, do @kbd{M-x
+ compile}.  This command reads a shell command line using the minibuffer,
+ and then executes the command in an inferior shell, putting output in
+ the buffer named @samp{*compilation*}.  The current buffer's default
+ directory is used as the working directory for the execution of the
+ command; normally, therefore, the compilation happens in this
+ directory.
+ 
+ @vindex compile-command
+   When the shell command line is read, the minibuffer appears
+ containing a default command line, which is the command you used the
+ last time you did @kbd{M-x compile}.  If you type just @key{RET}, the
+ same command line is used again.  For the first @kbd{M-x compile}, the
+ default is @samp{make -k}, which is correct most of the time for
+ nontrivial programs.  (@xref{Top,, Make, make, GNU Make Manual}.)
+ The default compilation command comes from the variable
+ @code{compile-command}; if the appropriate compilation command for a
+ file is something other than @samp{make -k}, it can be useful for the
+ file to specify a local value for @code{compile-command} (@pxref{File
+ Variables}).
+ 
+   Starting a compilation displays the buffer @samp{*compilation*} in
+ another window but does not select it.  The buffer's mode line tells you
+ whether compilation is finished, with the word @samp{run} or @samp{exit}
+ inside the parentheses.  You do not have to keep this buffer visible;
+ compilation continues in any case.  While a compilation is going on, the
+ string @samp{Compiling} appears in the mode lines of all windows.  When
+ this string disappears, the compilation is finished.
+ 
+   If you want to watch the compilation transcript as it appears, switch
+ to the @samp{*compilation*} buffer and move point to the end of the
+ buffer.  When point is at the end, new compilation output is inserted
+ above point, which remains at the end.  If point is not at the end of
+ the buffer, it remains fixed while more compilation output is added at
+ the end of the buffer.
+ 
+ @cindex compilation buffer, keeping current position at the end
+ @vindex compilation-scroll-output
+   If you set the variable @code{compilation-scroll-output} to a
+ address@hidden value, then the compilation buffer always scrolls to
+ follow output as it comes in.
+ 
+ @findex kill-compilation
+   When the compiler process terminates, for whatever reason, the mode
+ line of the @samp{*compilation*} buffer changes to say @samp{signal}
+ instead of @samp{run}.  Starting a new compilation also kills any
+ running compilation, as only one can exist at any time.  However,
+ @kbd{M-x compile} asks for confirmation before actually killing a
+ compilation that is running.  You can also kill the compilation
+ process with @kbd{M-x kill-compilation}.
+ 
+ @findex recompile
+   To rerun the last compilation with the same command, type @kbd{M-x
+ recompile}.  This automatically reuses the compilation command from the
+ last invocation of @kbd{M-x compile}.
+ 
+   Emacs does not expect a compiler process to launch asynchronous
+ subprocesses; if it does, and they keep running after the main
+ compiler process has terminated, Emacs may kill them or their output
+ may not arrive in Emacs.  To avoid this problem, make the main process
+ wait for its subprocesses to finish.  In a shell script, you can do this
+ using @samp{$!} and @samp{wait}, like this:
+ 
+ @example
+ (sleep 10; echo 2nd)& pid=$!  # @r{Record pid of subprocess}
+ echo first message
+ wait $pid                     # @r{Wait for subprocess}
+ @end example
+ 
+ @node Grep Searching
+ @section Searching with Grep under Emacs
+ 
+ @findex grep
+   Just as you can run a compiler from Emacs and then visit the lines
+ where there were compilation errors, you can also run @code{grep} and
+ then visit the lines on which matches were found.  This works by
+ treating the matches reported by @code{grep} as if they were ``errors.''
+ 
+   To do this, type @kbd{M-x grep}, then enter a command line that
+ specifies how to run @code{grep}.  Use the same arguments you would give
+ @code{grep} when running it normally: a @code{grep}-style regexp
+ (usually in single-quotes to quote the shell's special characters)
+ followed by file names, which may use wildcards.  The output from
+ @code{grep} goes in the @samp{*grep*} buffer.  You can find the
+ corresponding lines in the original files using @kbd{C-x `} and
+ @key{RET}, as with compilation errors.
+ 
+   If you specify a prefix argument for @kbd{M-x grep}, it figures out
+ the tag (@pxref{Tags}) around point, and puts that into the default
+ @code{grep} command.
+ 
+ @findex grep-find
+   The command @kbd{M-x grep-find} is similar to @kbd{M-x grep}, but it
+ supplies a different initial default for the command---one that runs
+ both @code{find} and @code{grep}, so as to search every file in a
+ directory tree.  See also the @code{find-grep-dired} command,
+ in @ref{Dired and Find}.
+ 
+ @node Compilation Mode
+ @section Compilation Mode
+ 
+ @findex compile-goto-error
+ @cindex Compilation mode
+ @cindex mode, Compilation
+   The @samp{*compilation*} buffer uses a special major mode, Compilation
+ mode, whose main feature is to provide a convenient way to look at the
+ source line where the error happened.
+ 
+   If you set the variable @code{compilation-scroll-output} to a
+ address@hidden value, then the compilation buffer always scrolls to
+ follow output as it comes in.
+ 
+ @table @kbd
+ @item C-x `
+ Visit the locus of the next compiler error message or @code{grep} match.
+ @item @key{RET}
+ Visit the locus of the error message that point is on.
+ This command is used in the compilation buffer.
+ @item Mouse-2
+ Visit the locus of the error message that you click on.
+ @end table
+ 
+ @kindex C-x `
+ @findex next-error
+   You can visit the source for any particular error message by moving
+ point in the @samp{*compilation*} buffer to that error message and
+ typing @key{RET} (@code{compile-goto-error}).  Alternatively, you can
+ click @kbd{Mouse-2} on the error message; you need not switch to the
+ @samp{*compilation*} buffer first.
+ 
+   To parse the compiler error messages sequentially, type @kbd{C-x `}
+ (@code{next-error}).  The character following the @kbd{C-x} is the
+ backquote or ``grave accent,'' not the single-quote.  This command is
+ available in all buffers, not just in @samp{*compilation*}; it displays
+ the next error message at the top of one window and source location of
+ the error in another window.
+ 
+   The first time @kbd{C-x `} is used after the start of a compilation,
+ it moves to the first error's location.  Subsequent uses of @kbd{C-x `}
+ advance down to subsequent errors.  If you visit a specific error
+ message with @key{RET} or @kbd{Mouse-2}, subsequent @kbd{C-x `}
+ commands advance from there.  When @kbd{C-x `} gets to the end of the
+ buffer and finds no more error messages to visit, it fails and signals
+ an Emacs error.
+ 
+   You don't have to be in the compilation buffer in order to use
+ @code{next-error}.  If one window on the selected frame can be the
+ target of the @code{next-error} call, it is used.  Else, if a buffer
+ previously had @code{next-error} called on it, it is used.  Else,
+ if the current buffer can be the target of @code{next-error}, it is
+ used.  Else, all the buffers Emacs manages are tried for
+ @code{next-error} support.
+ 
+   @kbd{C-u C-x `} starts scanning from the beginning of the compilation
+ buffer.  This is one way to process the same set of errors again.
+ 
+ @vindex compilation-error-regexp-alist
+ @vindex grep-regexp-alist
+   To parse messages from the compiler, Compilation mode uses the
+ variable @code{compilation-error-regexp-alist} which lists various
+ formats of error messages and tells Emacs how to extract the source file
+ and the line number from the text of a message.  If your compiler isn't
+ supported, you can tailor Compilation mode to it by adding elements to
+ that list.  A similar variable @code{grep-regexp-alist} tells Emacs how
+ to parse output of a @code{grep} command.
+ 
+   Compilation mode also redefines the keys @key{SPC} and @key{DEL} to
+ scroll by screenfuls, and @kbd{M-n} and @kbd{M-p} to move to the next or
+ previous error message.  You can also use @address@hidden and @address@hidden 
to
+ move up or down to an error message for a different source file.
+ 
+   The features of Compilation mode are also available in a minor mode
+ called Compilation Minor mode.  This lets you parse error messages in
+ any buffer, not just a normal compilation output buffer.  Type @kbd{M-x
+ compilation-minor-mode} to enable the minor mode.  This defines the keys
+ @key{RET} and @kbd{Mouse-2}, as in the Compilation major mode.
+ 
+   Compilation minor mode works in any buffer, as long as the contents
+ are in a format that it understands.  In an Rlogin buffer (@pxref{Remote
+ Host}), Compilation minor mode automatically accesses remote source
+ files by FTP (@pxref{File Names}).
+ 
+ @node Compilation Shell
+ @section Subshells for Compilation
+ 
+   Emacs uses a shell to run the compilation command, but specifies
+ the option for a noninteractive shell.  This means, in particular, that
+ the shell should start with no prompt.  If you find your usual shell
+ prompt making an unsightly appearance in the @samp{*compilation*}
+ buffer, it means you have made a mistake in your shell's init file by
+ setting the prompt unconditionally.  (This init file's name may be
+ @file{.bashrc}, @file{.profile}, @file{.cshrc}, @file{.shrc}, or various
+ other things, depending on the shell you use.)  The shell init file
+ should set the prompt only if there already is a prompt.  In csh, here
+ is how to do it:
+ 
+ @example
+ if ($?prompt) set prompt = @dots{}
+ @end example
+ 
+ @noindent
+ And here's how to do it in bash:
+ 
+ @example
+ if [ "address@hidden@}" = set ]
+ then address@hidden
+ fi
+ @end example
+ 
+   There may well be other things that your shell's init file
+ ought to do only for an interactive shell.  You can use the same
+ method to conditionalize them.
+ 
+   The MS-DOS ``operating system'' does not support asynchronous
+ subprocesses; to work around this lack, @kbd{M-x compile} runs the
+ compilation command synchronously on MS-DOS.  As a consequence, you must
+ wait until the command finishes before you can do anything else in
+ Emacs.  @xref{MS-DOS}.
+ 
+ @node Debuggers
+ @section Running Debuggers Under Emacs
+ @cindex debuggers
+ @cindex GUD library
+ @cindex GDB
+ @cindex DBX
+ @cindex SDB
+ @cindex XDB
+ @cindex Perldb
+ @cindex JDB
+ @cindex PDB
+ 
+ @c Do you believe in GUD?
+ The GUD (Grand Unified Debugger) library provides an interface to
+ various symbolic debuggers from within Emacs.  We recommend the debugger
+ GDB, which is free software, but you can also run DBX, SDB or XDB if you
+ have them.  GUD can also serve as an interface to Perl's debugging
+ mode, the Python debugger PDB, and to JDB, the Java Debugger.
+ @xref{Debugging,, The Lisp Debugger, elisp, the Emacs Lisp Reference Manual},
+ for information on debugging Emacs Lisp programs.
+ 
+ @menu
+ * Starting GUD::      How to start a debugger subprocess.
+ * Debugger Operation::        Connection between the debugger and source 
buffers.
+ * Commands of GUD::   Key bindings for common commands.
+ * GUD Customization:: Defining your own commands for GUD.
+ * GUD Tooltips::        Showing variable values by pointing with the mouse.
+ * GDB Graphical Interface::  An enhanced mode that uses GDB features to
+                         implement a graphical debugging environment through
+                         Emacs.
+ @end menu
+ 
+ @node Starting GUD
+ @subsection Starting GUD
+ 
+   There are several commands for starting a debugger, each corresponding
+ to a particular debugger program.
+ 
+ @table @kbd
+ @item M-x gdb @key{RET} @var{file} @key{RET}
+ @findex gdb
+ Run GDB as a subprocess of Emacs.  If the variable
+ @code{gud-gdb-command-name} is ``gdb --annotate=3'' (the default
+ value) then GDB starts as for @kbd{M-x gdba} below.  If you want to
+ GDB to start as in Emacs 21.3 and earlier then set
+ @code{gud-gdb-command-name} to ``gdb --fullname''.  In this case, the
+ command creates a buffer for input and output to GDB, and switches to
+ it.  If a GDB buffer already exists, it just switches to that buffer.
+ 
+ @item M-x gdba @key{RET} @var{file} @key{RET}
+ Run GDB as a subprocess of Emacs, providing a graphical interface
+ to GDB features through Emacs.  @xref{GDB Graphical Interface}.
+ 
+ @item M-x dbx @key{RET} @var{file} @key{RET}
+ @findex dbx
+ Similar, but run DBX instead of GDB.
+ 
+ @item M-x xdb @key{RET} @var{file} @key{RET}
+ @findex xdb
+ @vindex gud-xdb-directories
+ Similar, but run XDB instead of GDB.  Use the variable
+ @code{gud-xdb-directories} to specify directories to search for source
+ files.
+ 
+ @item M-x sdb @key{RET} @var{file} @key{RET}
+ @findex sdb
+ Similar, but run SDB instead of GDB.
+ 
+   Some versions of SDB do not mention source file names in their
+ messages.  When you use them, you need to have a valid tags table
+ (@pxref{Tags}) in order for GUD to find functions in the source code.
+ If you have not visited a tags table or the tags table doesn't list one
+ of the functions, you get a message saying @samp{The sdb support
+ requires a valid tags table to work}.  If this happens, generate a valid
+ tags table in the working directory and try again.
+ 
+ @item M-x perldb @key{RET} @var{file} @key{RET}
+ @findex perldb
+ Run the Perl interpreter in debug mode to debug @var{file}, a Perl program.
+ 
+ @item M-x jdb @key{RET} @var{file} @key{RET}
+ @findex jdb
+ Run the Java debugger to debug @var{file}.
+ 
+ @item M-x pdb @key{RET} @var{file} @key{RET}
+ @findex pdb
+ Run the Python debugger to debug @var{file}.
+ @end table
+ 
+   Each of these commands takes one argument: a command line to invoke
+ the debugger.  In the simplest case, specify just the name of the
+ executable file you want to debug.  You may also use options that the
+ debugger supports.  However, shell wildcards and variables are not
+ allowed.  GUD assumes that the first argument not starting with a
+ @samp{-} is the executable file name.
+ 
+   Emacs can only run one debugger process at a time.
+ 
+ @node Debugger Operation
+ @subsection Debugger Operation
+ 
+ @cindex fringes, and current execution line in GUD
+   When you run a debugger with GUD, the debugger uses an Emacs buffer
+ for its ordinary input and output.  This is called the GUD buffer.  The
+ debugger displays the source files of the program by visiting them in
+ Emacs buffers.  An arrow (@samp{=>}) in one of these buffers indicates
+ the current execution address@hidden a window system, the arrow
+ appears in the left fringe of the Emacs window.}  Moving point in this
+ buffer does not move the arrow.
+ 
+   You can start editing these source files at any time in the buffers
+ that display them.  The arrow is not part of the file's
+ text; it appears only on the screen.  If you do modify a source file,
+ keep in mind that inserting or deleting lines will throw off the arrow's
+ positioning; GUD has no way of figuring out which line corresponded
+ before your changes to the line number in a debugger message.  Also,
+ you'll typically have to recompile and restart the program for your
+ changes to be reflected in the debugger's tables.
+ 
+   If you wish, you can control your debugger process entirely through the
+ debugger buffer, which uses a variant of Shell mode.  All the usual
+ commands for your debugger are available, and you can use the Shell mode
+ history commands to repeat them.  @xref{Shell Mode}.
+ 
+ @node Commands of GUD
+ @subsection Commands of GUD
+ 
+   The GUD interaction buffer uses a variant of Shell mode, so the
+ commands of Shell mode are available (@pxref{Shell Mode}).  GUD mode
+ also provides commands for setting and clearing breakpoints, for
+ selecting stack frames, and for stepping through the program.  These
+ commands are available both in the GUD buffer and globally, but with
+ different key bindings.  It also has its own toolbar from which you
+ can invoke the more common commands by clicking on the appropriate
+ icon.  This is particularly useful for repetitive commands like
+ gud-next and gud-step and allows the user to hide the GUD buffer.
+ 
+   The breakpoint commands are normally used in source file buffers,
+ because that is the easiest way to specify where to set or clear the
+ breakpoint.  Here's the global command to set a breakpoint:
+ 
+ @table @kbd
+ @item C-x @key{SPC}
+ @kindex C-x SPC
+ Set a breakpoint on the source line that point is on.
+ @end table
+ 
+ @kindex C-x C-a @r{(GUD)}
+   Here are the other special commands provided by GUD.  The keys
+ starting with @kbd{C-c} are available only in the GUD interaction
+ buffer.  The key bindings that start with @kbd{C-x C-a} are available in
+ the GUD interaction buffer and also in source files.
+ 
+ @table @kbd
+ @item C-c C-l
+ @kindex C-c C-l @r{(GUD)}
+ @itemx C-x C-a C-l
+ @findex gud-refresh
+ Display in another window the last line referred to in the GUD
+ buffer (that is, the line indicated in the last location message).
+ This runs the command @code{gud-refresh}.
+ 
+ @item C-c C-s
+ @kindex C-c C-s @r{(GUD)}
+ @itemx C-x C-a C-s
+ @findex gud-step
+ Execute a single line of code (@code{gud-step}).  If the line contains
+ a function call, execution stops after entering the called function.
+ 
+ @item C-c C-n
+ @kindex C-c C-n @r{(GUD)}
+ @itemx C-x C-a C-n
+ @findex gud-next
+ Execute a single line of code, stepping across entire function calls
+ at full speed (@code{gud-next}).
+ 
+ @item C-c C-i
+ @kindex C-c C-i @r{(GUD)}
+ @itemx C-x C-a C-i
+ @findex gud-stepi
+ Execute a single machine instruction (@code{gud-stepi}).
+ 
+ @need 3000
+ @item C-c C-r
+ @kindex C-c C-r @r{(GUD)}
+ @itemx C-x C-a C-r
+ @findex gud-cont
+ Continue execution without specifying any stopping point.  The program
+ will run until it hits a breakpoint, terminates, or gets a signal that
+ the debugger is checking for (@code{gud-cont}).
+ 
+ @need 1000
+ @item C-c C-d
+ @kindex C-c C-d @r{(GUD)}
+ @itemx C-x C-a C-d
+ @findex gud-remove
+ Delete the breakpoint(s) on the current source line, if any
+ (@code{gud-remove}).  If you use this command in the GUD interaction
+ buffer, it applies to the line where the program last stopped.
+ 
+ @item C-c C-t
+ @kindex C-c C-t @r{(GUD)}
+ @itemx C-x C-a C-t
+ @findex gud-tbreak
+ Set a temporary breakpoint on the current source line, if any.
+ If you use this command in the GUD interaction buffer,
+ it applies to the line where the program last stopped.
+ @end table
+ 
+   The above commands are common to all supported debuggers.  If you are
+ using GDB or (some versions of) DBX, these additional commands are available:
+ 
+ @table @kbd
+ @item C-c <
+ @kindex C-c < @r{(GUD)}
+ @itemx C-x C-a <
+ @findex gud-up
+ Select the next enclosing stack frame (@code{gud-up}).  This is
+ equivalent to the @samp{up} command.
+ 
+ @item C-c >
+ @kindex C-c > @r{(GUD)}
+ @itemx C-x C-a >
+ @findex gud-down
+ Select the next inner stack frame (@code{gud-down}).  This is
+ equivalent to the @samp{down} command.
+ @end table
+ 
+   If you are using GDB, these additional key bindings are available:
+ 
+ @table @kbd
+ @item C-c C-r
+ @kindex C-c C-r @r{(GUD)}
+ @itemx C-x C-a C-r
+ @findex gud-run
+ Start execution of the program (@code{gud-run}).
+ 
+ @item C-c C-u
+ @kindex C-c C-u @r{(GUD)}
+ @itemx C-x C-a C-u
+ @findex gud-until
+ Continue execution to the current line. The program will run until
+ it hits a breakpoint, terminates, gets a signal that the debugger is
+ checking for, or reaches the line on which the cursor currently sits
+ (@code{gud-until}).
+ 
+ @item @key{TAB}
+ @kindex TAB @r{(GUD)}
+ @findex gud-gdb-complete-command
+ With GDB, complete a symbol name (@code{gud-gdb-complete-command}).
+ This key is available only in the GUD interaction buffer, and requires
+ GDB versions 4.13 and later.
+ 
+ @item C-c C-f
+ @kindex C-c C-f @r{(GUD)}
+ @itemx C-x C-a C-f
+ @findex gud-finish
+ Run the program until the selected stack frame returns (or until it
+ stops for some other reason).
+ 
+ @item C-x C-a C-j
+ @kindex C-x C-a C-j @r{(GUD)}
+ @findex gud-jump
+ Only useful in a source buffer, (@code{gud-jump}) transfers the
+ program's execution point to the current line.  In other words, the
+ next line that the program executes will be the one where you gave the
+ command.  If the new execution line is in a different function from
+ the previously one, GDB prompts for confirmation since the results may
+ be bizarre.  See the GDB manual entry regarding @code{jump} for
+ details.
+ @end table
+ 
+ If you started GDB with the command @code{gdba}, you can click
+ @kbd{Mouse-1} on a line of the source buffer, in the fringe or display
+ margin, to set a breakpoint there.  If a breakpoint already exists on
+ that line, this action will remove it.
+ (@code{gdb-mouse-toggle-breakpoint}).
+ 
+   These commands interpret a numeric argument as a repeat count, when
+ that makes sense.
+ 
+   Because @key{TAB} serves as a completion command, you can't use it to
+ enter a tab as input to the program you are debugging with GDB.
+ Instead, type @kbd{C-q @key{TAB}} to enter a tab.
+ 
+ @node GUD Customization
+ @subsection GUD Customization
+ 
+ @vindex gdb-mode-hook
+ @vindex dbx-mode-hook
+ @vindex sdb-mode-hook
+ @vindex xdb-mode-hook
+ @vindex perldb-mode-hook
+ @vindex pdb-mode-hook
+ @vindex jdb-mode-hook
+   On startup, GUD runs one of the following hooks: @code{gdb-mode-hook},
+ if you are using GDB; @code{dbx-mode-hook}, if you are using DBX;
+ @code{sdb-mode-hook}, if you are using SDB; @code{xdb-mode-hook}, if you
+ are using XDB; @code{perldb-mode-hook}, for Perl debugging mode;
+ @code{pdb-mode-hook}, for PDB; @code{jdb-mode-hook}, for JDB.  You can
+ use these hooks to define custom key bindings for the debugger
+ interaction buffer.  @xref{Hooks}.
+ 
+   Here is a convenient way to define a command that sends a particular
+ command string to the debugger, and set up a key binding for it in the
+ debugger interaction buffer:
+ 
+ @findex gud-def
+ @example
+ (gud-def @var{function} @var{cmdstring} @var{binding} @var{docstring})
+ @end example
+ 
+   This defines a command named @var{function} which sends
+ @var{cmdstring} to the debugger process, and gives it the documentation
+ string @var{docstring}.  You can then use the command @var{function} in any
+ buffer.  If @var{binding} is address@hidden, @code{gud-def} also binds
+ the command to @kbd{C-c @var{binding}} in the GUD buffer's mode and to
+ @kbd{C-x C-a @var{binding}} generally.
+ 
+   The command string @var{cmdstring} may contain certain
+ @samp{%}-sequences that stand for data to be filled in at the time
+ @var{function} is called:
+ 
+ @table @samp
+ @item %f
+ The name of the current source file.  If the current buffer is the GUD
+ buffer, then the ``current source file'' is the file that the program
+ stopped in.
+ @c This said, ``the name of the file the program counter was in at the last 
breakpoint.''
+ @c But I suspect it is really the last stop file.
+ 
+ @item %l
+ The number of the current source line.  If the current buffer is the GUD
+ buffer, then the ``current source line'' is the line that the program
+ stopped in.
+ 
+ @item %e
+ The text of the C lvalue or function-call expression at or adjacent to point.
+ 
+ @item %a
+ The text of the hexadecimal address at or adjacent to point.
+ 
+ @item %p
+ The numeric argument of the called function, as a decimal number.  If
+ the command is used without a numeric argument, @samp{%p} stands for the
+ empty string.
+ 
+ If you don't use @samp{%p} in the command string, the command you define
+ ignores any numeric argument.
+ @end table
+ 
+ @node GUD Tooltips
+ @subsection GUD Tooltips
+ 
+ @cindex tooltips with GUD
+ The Tooltip facility (@pxref{Tooltips}) provides support for address@hidden  
If
+ GUD support is activated by customizing the @code{tooltip} group,
+ variable values can be displayed in tooltips by pointing at them with
+ the mouse in the GUD buffer or in source buffers with major modes in the
+ customizable list @code{tooltip-gud-modes}.
+ 
+ @node GDB Graphical Interface
+ @subsection GDB Graphical Interface
+ 
+ @findex gdba
+ The command @code{gdba} starts GDB using a graphical interface where
+ you view and control the program's data using Emacs windows.  You can
+ still interact with GDB through the GUD buffer, but the point of this
+ mode is that you can do it through menus and clicks, without needing
+ to know GDB commands.
+ 
+ @menu
+ * Layout::               Control the number of displayed buffers.
+ * Breakpoints Buffer::   A breakpoint control panel.
+ * Stack Buffer::         Select a frame from the call stack.
+ * Watch Expressions::    Monitor variable values in the speedbar.
+ * Other Buffers::        Input/output, locals, registers and assembler 
buffers.
+ @end menu
+ 
+ @node Layout
+ @subsubsection Layout
+ @cindex GDB User Interface layout
+ 
+ @findex gdb-many-windows
+ @vindex gdb-many-windows
+ 
+ If the variable @code{gdb-many-windows} is @code{nil} (the default
+ value) then gdb just pops up the GUD buffer unless the variable
+ @code{gdb-show-main} is address@hidden  In this case it starts with
+ two windows: one displaying the GUD buffer and the other with the
+ source file with the main routine of the inferior.
+ 
+ If @code{gdb-many-windows} is address@hidden, regardless of the value of
+ @code{gdb-show-main}, the layout below will appear unless
+ @code{gdb-use-inferior-io-buffer} is @code{nil}.  In this case the
+ source buffer occupies the full width of the frame.
+ 
+ @multitable @columnfractions .5 .5
+ @item GUD buffer (I/O of GDB)
+ @tab Locals buffer
+ @item
+ @tab
+ @item Source buffer
+ @tab Input/Output (of inferior) buffer
+ @item
+ @tab
+ @item Stack buffer
+ @tab Breakpoints buffer
+ @end multitable
+ 
+ To toggle this layout, do @kbd{M-x gdb-many-windows}.
+ 
+ @findex gdb-restore-windows
+ If you change the window layout, for example, while editing and
+ re-compiling your program, then you can restore it with the command
+ @code{gdb-restore-windows}.
+ 
+ You may also choose which additional buffers you want to display,
+ either in the same frame or a different one.  Select GDB-windows or
+ GDB-Frames from the menu-bar under the heading GUD.  If the menu-bar
+ is unavailable, type @code{M-x
+ address@hidden or @code{M-x
+ address@hidden respectively, where @var{buffertype}
+ is the relevant buffer type e.g breakpoints.
+ 
+ @node Breakpoints Buffer
+ @subsubsection Breakpoints Buffer
+ 
+ The breakpoints buffer shows the existing breakpoints and watchpoints
+ (@pxref{Breakpoints,,, gdb, The GNU debugger}).  It has three special
+ commands:
+ 
+ @table @kbd
+ @item @key{SPC}
+ @kindex SPC @r{(GDB breakpoints buffer)}
+ @findex gdb-toggle-breakpoint
+ Enable/disable the breakpoint at the current line
+ (@code{gdb-toggle-breakpoint}).  On a graphical display, this changes
+ the color of a bullet in the margin of the source buffer at the
+ relevant line.  This is red when the breakpoint is enabled and grey
+ when it is disabled.  Text-only terminals correspondingly display
+ a @samp{B} or @samp{b}.
+ 
+ @item @kbd{d}
+ @kindex d @r{(GDB breakpoints buffer)}
+ @findex gdb-delete-breakpoint
+ Delete the breakpoint at the current line (@code{gdb-delete-breakpoint}).
+ 
+ @item @key{RET}
+ @kindex RET @r{(GDB breakpoints buffer)}
+ @findex gdb-goto-breakpoint
+ Display the file in the source buffer at the breakpoint specified at
+ the current line (@code{gdb-goto-breakpoint}).  Alternatively, click 
@kbd{Mouse-2} on the breakpoint that you wish to visit.
+ @end table
+ 
+ @node Stack Buffer
+ @subsubsection Stack Buffer
+ 
+ The stack buffer displays a @dfn{call stack}, with one line for each
+ of the nested subroutine calls (@dfn{stack frames}) now active in the
+ program.  @xref{Backtrace,,info stack, gdb, The GNU debugger}.
+ 
+ Move point to any frame in the stack and type @key{RET} to make it
+ become the current frame (@code{gdb-frames-select}) and display the
+ associated source in the source buffer.  Alternatively, click
+ @kbd{Mouse-2} to make the selected frame become the current one.  If the
+ locals buffer is displayed then its contents update to display the
+ variables that are local to the new frame.
+ 
+ @node Watch Expressions
+ @subsubsection Watch Expressions
+ @cindex Watching expressions in GDB
+ 
+ If you want to see how a variable changes each time your program stops
+ then place the cursor over the variable name and click on the watch
+ icon in the toolbar (@code{gud-watch}).
+ 
+ Each watch expression is displayed in the speedbar.  Complex data
+ types, such as arrays, structures and unions are represented in a tree
+ format.  To expand or contract a complex data type, click @kbd{Mouse-2}
+ on the tag to the left of the expression.
+ 
+ @kindex RET @r{(GDB speedbar)}
+ @findex gdb-var-delete
+ With the cursor over the root expression of a complex data type, type
+ @kbd{D} to delete it from the speedbar
+ (@code{gdb-var-delete}).
+ 
+ @findex gdb-edit-value
+ With the cursor over a simple data type or an element of a complex
+ data type which holds a value, type @key{RET} or click @kbd{Mouse-2} to edit
+ its value.  A prompt for a new value appears in the mini-buffer
+ (@code{gdb-edit-value}).
+ 
+ If you set the variable @code{gdb-show-changed-values} to
+ address@hidden (the default value), then Emacs will use
+ font-lock-warning-face to display values that have recently changed in
+ the speedbar.
+ 
+ If you set the variable @code{gdb-use-colon-colon-notation} to a
+ address@hidden value, then, in C, Emacs will use the
+ FUNCTION::VARIABLE format to display variables in the speedbar.
+ Since this does not work for variables defined in compound statements,
+ the default value is @code{nil}.
+ 
+ @node Other Buffers
+ @subsubsection Other Buffers
+ 
+ @table @asis
+ @item Input/Output Buffer
+ If the variable @code{gdb-use-inferior-io-buffer} is address@hidden,
+ the executable program that is being debugged takes its input and
+ displays its output here.  Some of the commands from shell mode are
+ available here.  @xref{Shell Mode}.
+ 
+ @item Locals Buffer
+ The locals buffer displays the values of local variables of the
+ current frame for simple data types (@pxref{Frame Info,,, gdb, The GNU
+ debugger}).
+ 
+ Arrays and structures display their type only.  You must display them
+ separately to examine their values.  @ref{Watch Expressions}.
+ 
+ @item Registers Buffer
+ The registers buffer displays the values held by the registers
+ (@pxref{Registers,,, gdb, The GNU debugger}).
+ 
+ @item Assembler Buffer
+ The assembler buffer displays the current frame as machine code.  An
+ overlay arrow points to the current instruction and you can set and
+ remove breakpoints as with the source buffer.  Breakpoints also
+ appear in the margin.
+ 
+ @item Threads Buffer
+ 
+ The threads buffer displays a summary of all threads currently in your
+ program.(@pxref{Threads,,, gdb, The GNU debugger}).  Move point to
+ any thread in the list and type @key{RET} to make it become the
+ current thread (@code{gdb-threads-select}) and display the associated
+ source in the source buffer.  Alternatively, click @kbd{Mouse-2} to
+ make the selected thread become the current one.
+ 
+ @end table
+ 
+ @node Executing Lisp
+ @section Executing Lisp Expressions
+ 
+   Emacs has several different major modes for Lisp and Scheme.  They are
+ the same in terms of editing commands, but differ in the commands for
+ executing Lisp expressions.  Each mode has its own purpose.
+ 
+ @table @asis
+ @item Emacs-Lisp mode
+ The mode for editing source files of programs to run in Emacs Lisp.
+ This mode defines @kbd{C-M-x} to evaluate the current defun.
+ @xref{Lisp Libraries}.
+ @item Lisp Interaction mode
+ The mode for an interactive session with Emacs Lisp.  It defines
+ @kbd{C-j} to evaluate the sexp before point and insert its value in the
+ buffer.  @xref{Lisp Interaction}.
+ @item Lisp mode
+ The mode for editing source files of programs that run in Lisps other
+ than Emacs Lisp.  This mode defines @kbd{C-M-x} to send the current defun
+ to an inferior Lisp process.  @xref{External Lisp}.
+ @item Inferior Lisp mode
+ The mode for an interactive session with an inferior Lisp process.
+ This mode combines the special features of Lisp mode and Shell mode
+ (@pxref{Shell Mode}).
+ @item Scheme mode
+ Like Lisp mode but for Scheme programs.
+ @item Inferior Scheme mode
+ The mode for an interactive session with an inferior Scheme process.
+ @end table
+ 
+   Most editing commands for working with Lisp programs are in fact
+ available globally.  @xref{Programs}.
+ 
+ @node Lisp Libraries
+ @section Libraries of Lisp Code for Emacs
+ @cindex libraries
+ @cindex loading Lisp code
+ 
+   Lisp code for Emacs editing commands is stored in files whose names
+ conventionally end in @file{.el}.  This ending tells Emacs to edit them in
+ Emacs-Lisp mode (@pxref{Executing Lisp}).
+ 
+ @findex load-file
+   To execute a file of Emacs Lisp code, use @kbd{M-x load-file}.  This
+ command reads a file name using the minibuffer and then executes the
+ contents of that file as Lisp code.  It is not necessary to visit the
+ file first; in any case, this command reads the file as found on disk,
+ not text in an Emacs buffer.
+ 
+ @findex load
+ @findex load-library
+   Once a file of Lisp code is installed in the Emacs Lisp library
+ directories, users can load it using @kbd{M-x load-library}.  Programs can
+ load it by calling @code{load-library}, or with @code{load}, a more primitive
+ function that is similar but accepts some additional arguments.
+ 
+   @kbd{M-x load-library} differs from @kbd{M-x load-file} in that it
+ searches a sequence of directories and tries three file names in each
+ directory.  Suppose your argument is @var{lib}; the three names are
+ @address@hidden, @address@hidden, and lastly just
+ @address@hidden  If @address@hidden exists, it is by convention
+ the result of compiling @address@hidden; it is better to load the
+ compiled file, since it will load and run faster.
+ 
+   If @code{load-library} finds that @address@hidden is newer than
+ @address@hidden file, it issues a warning, because it's likely that
+ somebody made changes to the @file{.el} file and forgot to recompile
+ it.
+ 
+   Because the argument to @code{load-library} is usually not in itself
+ a valid file name, file name completion is not available.  Indeed, when
+ using this command, you usually do not know exactly what file name
+ will be used.
+ 
+ @vindex load-path
+   The sequence of directories searched by @kbd{M-x load-library} is
+ specified by the variable @code{load-path}, a list of strings that are
+ directory names.  The default value of the list contains the directory where
+ the Lisp code for Emacs itself is stored.  If you have libraries of
+ your own, put them in a single directory and add that directory
+ to @code{load-path}.  @code{nil} in this list stands for the current default
+ directory, but it is probably not a good idea to put @code{nil} in the
+ list.  If you find yourself wishing that @code{nil} were in the list,
+ most likely what you really want to do is use @kbd{M-x load-file}
+ this once.
+ 
+ @cindex autoload
+   Often you do not have to give any command to load a library, because
+ the commands defined in the library are set up to @dfn{autoload} that
+ library.  Trying to run any of those commands calls @code{load} to load
+ the library; this replaces the autoload definitions with the real ones
+ from the library.
+ 
+ @cindex byte code
+   Emacs Lisp code can be compiled into byte-code which loads faster,
+ takes up less space when loaded, and executes faster.  @xref{Byte
+ Compilation,, Byte Compilation, elisp, the Emacs Lisp Reference Manual}.
+ By convention, the compiled code for a library goes in a separate file
+ whose name consists of the library source file with @samp{c} appended.
+ Thus, the compiled code for @file{foo.el} goes in @file{foo.elc}.
+ That's why @code{load-library} searches for @samp{.elc} files first.
+ 
+ @vindex load-dangerous-libraries
+ @cindex Lisp files byte-compiled by XEmacs
+   By default, Emacs refuses to load compiled Lisp files which were
+ compiled with XEmacs, a modified versions of Emacs---they can cause
+ Emacs to crash.  Set the variable @code{load-dangerous-libraries} to
+ @code{t} if you want to try loading them.
+ 
+ @node Lisp Eval
+ @section Evaluating Emacs-Lisp Expressions
+ @cindex Emacs-Lisp mode
+ @cindex mode, Emacs-Lisp
+ 
+ @findex emacs-lisp-mode
+   Lisp programs intended to be run in Emacs should be edited in
+ Emacs-Lisp mode; this happens automatically for file names ending in
+ @file{.el}.  By contrast, Lisp mode itself is used for editing Lisp
+ programs intended for other Lisp systems.  To switch to Emacs-Lisp mode
+ explicitly, use the command @kbd{M-x emacs-lisp-mode}.
+ 
+   For testing of Lisp programs to run in Emacs, it is often useful to
+ evaluate part of the program as it is found in the Emacs buffer.  For
+ example, after changing the text of a Lisp function definition,
+ evaluating the definition installs the change for future calls to the
+ function.  Evaluation of Lisp expressions is also useful in any kind of
+ editing, for invoking noninteractive functions (functions that are
+ not commands).
+ 
+ @table @kbd
+ @item M-:
+ Read a single Lisp expression in the minibuffer, evaluate it, and print
+ the value in the echo area (@code{eval-expression}).
+ @item C-x C-e
+ Evaluate the Lisp expression before point, and print the value in the
+ echo area (@code{eval-last-sexp}).
+ @item C-M-x
+ Evaluate the defun containing or after point, and print the value in
+ the echo area (@code{eval-defun}).
+ @item M-x eval-region
+ Evaluate all the Lisp expressions in the region.
+ @item M-x eval-current-buffer
+ Evaluate all the Lisp expressions in the buffer.
+ @end table
+ 
+ @ifinfo
+ @c This uses ``colon'' instead of a literal `:' because Info cannot
+ @c cope with a `:' in a menu
+ @kindex address@hidden
+ @end ifinfo
+ @ifnotinfo
+ @kindex M-:
+ @end ifnotinfo
+ @findex eval-expression
+   @kbd{M-:} (@code{eval-expression}) is the most basic command for evaluating
+ a Lisp expression interactively.  It reads the expression using the
+ minibuffer, so you can execute any expression on a buffer regardless of
+ what the buffer contains.  When the expression is evaluated, the current
+ buffer is once again the buffer that was current when @kbd{M-:} was
+ typed.
+ 
+ @kindex C-M-x @r{(Emacs-Lisp mode)}
+ @findex eval-defun
+   In Emacs-Lisp mode, the key @kbd{C-M-x} is bound to the command
+ @code{eval-defun}, which parses the defun containing or following point
+ as a Lisp expression and evaluates it.  The value is printed in the echo
+ area.  This command is convenient for installing in the Lisp environment
+ changes that you have just made in the text of a function definition.
+ 
+   @kbd{C-M-x} treats @code{defvar} expressions specially.  Normally,
+ evaluating a @code{defvar} expression does nothing if the variable it
+ defines already has a value.  But @kbd{C-M-x} unconditionally resets the
+ variable to the initial value specified in the @code{defvar} expression.
+ @code{defcustom} expressions are treated similarly.
+ This special feature is convenient for debugging Lisp programs.
+ Typing @kbd{C-M-x} on a @code{defface} expression reinitializes
+ the face according to the @code{defface} specification.
+ 
+ @kindex C-x C-e
+ @findex eval-last-sexp
+   The command @kbd{C-x C-e} (@code{eval-last-sexp}) evaluates the Lisp
+ expression preceding point in the buffer, and displays the value in the
+ echo area.  It is available in all major modes, not just Emacs-Lisp
+ mode.  It does not treat @code{defvar} specially.
+ 
+   If @kbd{C-M-x}, @kbd{C-x C-e}, or @kbd{M-:} is given a numeric
+ argument, it inserts the value into the current buffer at point, rather
+ than displaying it in the echo area.  The argument's value does not
+ matter.
+ 
+ @findex eval-region
+ @findex eval-current-buffer
+   The most general command for evaluating Lisp expressions from a buffer
+ is @code{eval-region}.  @kbd{M-x eval-region} parses the text of the
+ region as one or more Lisp expressions, evaluating them one by one.
+ @kbd{M-x eval-current-buffer} is similar but evaluates the entire
+ buffer.  This is a reasonable way to install the contents of a file of
+ Lisp code that you are ready to test.  Later, as you find bugs and
+ change individual functions, use @kbd{C-M-x} on each function that you
+ change.  This keeps the Lisp world in step with the source file.
+ 
+ @vindex eval-expression-print-level
+ @vindex eval-expression-print-length
+ @vindex eval-expression-debug-on-error
+ The customizable variables @code{eval-expression-print-level} and
+ @code{eval-expression-print-length} control the maximum depth and length
+ of lists to print in the result of the evaluation commands before
+ abbreviating them.  @code{eval-expression-debug-on-error} controls
+ whether evaluation errors invoke the debugger when these commands are
+ used.
+ 
+ @node Lisp Interaction
+ @section Lisp Interaction Buffers
+ 
+   The buffer @samp{*scratch*} which is selected when Emacs starts up is
+ provided for evaluating Lisp expressions interactively inside Emacs.
+ 
+   The simplest way to use the @samp{*scratch*} buffer is to insert Lisp
+ expressions and type @kbd{C-j} after each expression.  This command
+ reads the Lisp expression before point, evaluates it, and inserts the
+ value in printed representation before point.  The result is a complete
+ typescript of the expressions you have evaluated and their values.
+ 
+   The @samp{*scratch*} buffer's major mode is Lisp Interaction mode, which
+ is the same as Emacs-Lisp mode except for the binding of @kbd{C-j}.
+ 
+ @findex lisp-interaction-mode
+   The rationale for this feature is that Emacs must have a buffer when
+ it starts up, but that buffer is not useful for editing files since a
+ new buffer is made for every file that you visit.  The Lisp interpreter
+ typescript is the most useful thing I can think of for the initial
+ buffer to do.  Type @kbd{M-x lisp-interaction-mode} to put the current
+ buffer in Lisp Interaction mode.
+ 
+ @findex ielm
+   An alternative way of evaluating Emacs Lisp expressions interactively
+ is to use Inferior Emacs-Lisp mode, which provides an interface rather
+ like Shell mode (@pxref{Shell Mode}) for evaluating Emacs Lisp
+ expressions.  Type @kbd{M-x ielm} to create an @samp{*ielm*} buffer
+ which uses this mode.
+ 
+ @node External Lisp
+ @section Running an External Lisp
+ 
+   Emacs has facilities for running programs in other Lisp systems.  You can
+ run a Lisp process as an inferior of Emacs, and pass expressions to it to
+ be evaluated.  You can also pass changed function definitions directly from
+ the Emacs buffers in which you edit the Lisp programs to the inferior Lisp
+ process.
+ 
+ @findex run-lisp
+ @vindex inferior-lisp-program
+ @kindex C-x C-z
+   To run an inferior Lisp process, type @kbd{M-x run-lisp}.  This runs
+ the program named @code{lisp}, the same program you would run by typing
+ @code{lisp} as a shell command, with both input and output going through
+ an Emacs buffer named @samp{*lisp*}.  That is to say, any ``terminal
+ output'' from Lisp will go into the buffer, advancing point, and any
+ ``terminal input'' for Lisp comes from text in the buffer.  (You can
+ change the name of the Lisp executable file by setting the variable
+ @code{inferior-lisp-program}.)
+ 
+   To give input to Lisp, go to the end of the buffer and type the input,
+ terminated by @key{RET}.  The @samp{*lisp*} buffer is in Inferior Lisp
+ mode, which combines the special characteristics of Lisp mode with most
+ of the features of Shell mode (@pxref{Shell Mode}).  The definition of
+ @key{RET} to send a line to a subprocess is one of the features of Shell
+ mode.
+ 
+ @findex lisp-mode
+   For the source files of programs to run in external Lisps, use Lisp
+ mode.  This mode can be selected with @kbd{M-x lisp-mode}, and is used
+ automatically for files whose names end in @file{.l}, @file{.lsp}, or
+ @file{.lisp}, as most Lisp systems usually expect.
+ 
+ @kindex C-M-x @r{(Lisp mode)}
+ @findex lisp-eval-defun
+   When you edit a function in a Lisp program you are running, the easiest
+ way to send the changed definition to the inferior Lisp process is the key
+ @kbd{C-M-x}.  In Lisp mode, this runs the function @code{lisp-eval-defun},
+ which finds the defun around or following point and sends it as input to
+ the Lisp process.  (Emacs can send input to any inferior process regardless
+ of what buffer is current.)
+ 
+   Contrast the meanings of @kbd{C-M-x} in Lisp mode (for editing programs
+ to be run in another Lisp system) and Emacs-Lisp mode (for editing Lisp
+ programs to be run in Emacs): in both modes it has the effect of installing
+ the function definition that point is in, but the way of doing so is
+ different according to where the relevant Lisp environment is found.
+ @xref{Executing Lisp}.
+ 
+ @ignore
+    arch-tag: 9c3c2f71-b332-4144-8500-3ff9945a50ed
+ @end ignore