[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
1.1 Running ‘make’, or Compilers Generally | Compiling programs in languages other than Lisp (C, Pascal, etc.) | |
1.2 Major Modes for Lisp | Various modes for editing Lisp programs, with different facilities for running the Lisp programs. | |
1.3 Libraries of Lisp Code for Emacs | Creating Lisp programs to run in Emacs. | |
1.4 Evaluating Emacs-Lisp Expressions | Executing a single Lisp expression in Emacs. | |
1.5 The Emacs-Lisp Debugger | Debugging Lisp programs running in Emacs. | |
1.6 Lisp Interaction Buffers | Executing Lisp in an Emacs buffer. | |
1.7 Running an External Lisp | Communicating through Emacs with a separate Lisp. |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Emacs can run compilers for non-interactive languages like C and Fortran as inferior processes, feeding the error log into an Emacs buffer. It can also parse the error messages and visit the files in which errors are found, moving point to the line where the error occurred.
Run a compiler asynchronously under Emacs, with error messages to ‘*compilation*’ buffer.
Run grep
asynchronously under Emacs, with matching lines
listed in the buffer named ‘*compilation*’.
Kill the process made by the M-x compile
command.
Kill the running compilation or grep
subprocess.
Visit the next compiler error message or grep
match.
To run make
or another compiler, type M-x compile. This
command reads a shell command line using the minibuffer, then executes
the specified command line in an inferior shell with output going to the
buffer named ‘*compilation*’. By default, the current buffer’s
default directory is used as the working directory for the execution of
the command; therefore, the makefile comes from this directory.
When the shell command line is read, the minibuffer appears containing a
default command line (the command you used the last time you typed
M-x compile). If you type just <RET>, the same command line is used
again. The first M-x compile provides make -k
as the default.
The default is taken from the variable compile-command
; if the
appropriate compilation command for a file is something other than
make -k
, it can be useful to have the file specify a local value for
compile-command
(@pxref{File Variables}).
When you start a compilation, the buffer ‘*compilation*’ is displayed in another window but not selected. Its mode line displays the word ‘run’ or ‘exit’ in the parentheses to tell you whether compilation is finished. You do not have to keep this buffer visible; compilation continues in any case.
To kill the compilation process, type M-x-kill-compilation. The mode line of the ‘*compilation*’ buffer changes to say ‘signal’ instead of ‘run’. Starting a new compilation also kills any running compilation, as only one can occur at any time. Starting a new compilation prompts for confirmation before actually killing a compilation that is running.
To parse the compiler error messages, type C-x `
(next-error
). The character following C-x is the grave
accent, not the single quote. The command displays the buffer
‘*compilation*’ in one window and the buffer in which the next
error occurred in another window. Point in that buffer is moved to the
line where the error was found. The corresponding error message is
scrolled to the top of the window in which ‘*compilation*’ is
displayed.
The first time you use C-x ` after the start of a compilation, it parses all the error messages, visits all the files that have error messages, and creates markers pointing at the lines the error messages refer to. It then moves to the first error message location. Subsequent uses of C-x ` advance down the data set up by the first use. When the preparsed error messages are exhausted, the next C-x ` checks for any more error messages that have come in; this is useful if you start editing compiler errors while compilation is still going on. If no additional error messages have come in, C-x ` reports an error.
C-u C-x ` discards the preparsed error message data and parses the ‘*compilation*’ buffer again, then displays the first error. This way, you can process the same set of errors again.
Instead of running a compiler, you can run grep
and see the
lines on which matches were found. To do this, type M-x grep with
an argument line that contains the same arguments you would give to
grep
: a grep
-style regexp (usually in single quotes to
quote the shell’s special characters) followed by filenames, which may
use wildcard characters. The output from grep
goes in the
‘*compilation*’ buffer. You can use C-x ` to find the lines that
match as if they were compilation errors.
Note: a shell is used to run the compile command, but the shell is not
run in interactive mode. In particular, this means that the shell starts
up with no prompt. If you find your usual shell prompt making an
unsightly appearance in the ‘*compilation*’ buffer, it means you
have made a mistake in your shell’s initialization file (‘.cshrc’
or ‘.shrc’ or …) by setting the prompt unconditionally. The
shell initialization file should set the prompt only if there already is
a prompt. Here’s how to do it in csh
:
if ($?prompt) set prompt = ...
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Emacs has four different major modes for Lisp. They are the same in terms of editing commands, but differ in the commands for executing Lisp expressions.
The mode for editing source files of programs to run in Emacs Lisp. This mode defines C-M-x to evaluate the current defun. See section Libraries of Lisp Code for Emacs.
The mode for an interactive session with Emacs Lisp. It defines <LFD> to evaluate the sexp before point and insert its value in the buffer. See section Lisp Interaction Buffers.
The mode for editing source files of programs that run in other dialects of Lisp than Emacs Lisp. This mode defines C-M-x to send the current defun to an inferior Lisp process. See section Running an External Lisp.
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}).
Like Lisp mode but for Scheme programs.
The mode for an interactive session with an inferior Scheme process.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Lisp code for Emacs editing commands is stored in files whose names conventionally end in ‘.el’. This ending tells Emacs to edit them in Emacs-Lisp mode (see section Major Modes for Lisp).
1.3.1 Loading Libraries | Loading libraries of Lisp code into Emacs for use. | |
1.3.2 Compiling Libraries | Compiling a library makes it load and run faster. | |
1.3.3 Converting Mocklisp to Lisp | Converting Mocklisp to Lisp so XEmacs can run it. |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Load the file file of Lisp code.
Load the library named library.
Show the full path name of Emacs library library.
To execute a file of Emacs Lisp, use M-x load-file. This command reads the file name you provide in the minibuffer, then executes the contents of that file as Lisp code. It is not necessary to visit the file first; in fact, this command reads the file as found on disk, not the text in an Emacs buffer.
Once a file of Lisp code is installed in the Emacs Lisp library
directories, users can load it using M-x load-library. Programs can
load it by calling load-library
, or with load
, a more primitive
function that is similar but accepts some additional arguments.
M-x load-library differs from M-x load-file in that it searches a sequence of directories and tries three file names in each directory. The three names are: first, the specified name with ‘.elc’ appended; second, the name with ‘.el’ appended; third, the specified name alone. A ‘.elc’ file would be the result of compiling the Lisp file into byte code; if possible, it is loaded in preference to the Lisp file itself because the compiled file loads and runs faster.
Because the argument to load-library
is usually not in itself
a valid file name, file name completion is not available. In fact, when
using this command, you usually do not know exactly what file name
will be used.
The sequence of directories searched by M-x load-library is
specified by the variable load-path
, a list of strings that are
directory names. The elements of this list may not begin with "‘~’",
so you must call expand-file-name
on them before adding them to
the list. 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
load-path
. nil
in this list stands for the current
default directory, but it is probably not a good idea to put nil
in the list. If you start wishing that nil
were in the list, you
should probably use M-x load-file for this case.
The variable is initialized by the EMACSLOADPATH environment variable. If no value is specified, the variable takes the default value specified in the file ‘paths.h’ when Emacs was built. If a path isn’t specified in ‘paths.h’, a default value is obtained from the file system, near the directory in which the Emacs executable resides.
Like M-x load-library, M-x locate-library searches the
directories in load-path
to find the file that M-x load-library
would load. If the optional second argument nosuffix is
non-nil
, the suffixes ‘.elc’ or ‘.el’ are not added to
the specified name library (like calling load
instead of
load-library
).
You often do not have to give any command to load a library, because the
commands defined in the library are set up to autoload that library.
Running any of those commands causes load
to be called to load the
library; this replaces the autoload definitions with the real ones from the
library.
If autoloading a file does not finish, either because of an error or
because of a C-g quit, all function definitions made by the file
are undone automatically. So are any calls to provide
. As a
consequence, the entire file is loaded a second time if you use one of
the autoloadable commands again. This prevents problems when the
command is no longer autoloading but is working incorrectly because the file
was only partially loaded. Function definitions are undone only for
autoloading; explicit calls to load
do not undo anything if
loading is not completed.
The variable after-load-alist
takes an alist of expressions to be
evaluated when particular files are loaded. Each element has the form
(filename forms...)
. When load
is run and the filename
argument is filename, the forms in the corresponding element are
executed at the end of loading.
filename must match exactly. Normally filename is the
name of a library, with no directory specified, since that is how load
is normally called. An error in forms
does not undo the load, but
it does prevent execution of the rest of the forms
.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Emacs Lisp code can be compiled into byte-code which loads faster, takes up less space when loaded, and executes faster.
Run byte-compile-file on the files remaining on the command line.
Byte-compile and evaluate contents of buffer (default is current buffer).
Compile a file of Lisp code named filename into a file of byte code.
Compile a file of Lisp code named filename into a file of byte code and load it.
Recompile every ‘.el’ file in directory that needs recompilation.
Make the byte-compiler warn that function is obsolete and new should be used instead.
byte-compile-file creates a byte-code compiled file from an
Emacs-Lisp source file. The default argument for this function is the
file visited in the current buffer. The function reads the specified
file, compiles it into byte code, and writes an output file whose name
is made by appending ‘c’ to the input file name. Thus, the file
‘rmail.el’ would be compiled into ‘rmail.elc’. To compile a
file of Lisp code named filename into a file of byte code and
then load it, use byte-compile-and-load-file
. To compile and
evaluate Lisp code in a given buffer, use byte-compile-buffer
.
To recompile all changed Lisp files in a directory, use M-x byte-recompile-directory. Specify just the directory name as an argument. Each ‘.el’ file that has been byte-compiled before is byte-compiled again if it has changed since the previous compilation. A numeric argument to this command tells it to offer to compile each ‘.el’ file that has not been compiled yet. You must answer y or n to each offer.
You can use the function batch-byte-compile
to invoke Emacs
non-interactively from the shell to do byte compilation. When you use
this function, the files to be compiled are specified with command-line
arguments. Use a shell command of the form:
emacs -batch -f batch-byte-compile files...
Directory names may also be given as arguments; in that case,
byte-recompile-directory
is invoked on each such directory.
batch-byte-compile
uses all remaining command-line arguments as
file or directory names, then kills the Emacs process.
M-x disassemble explains the result of byte compilation. Its argument is a function name. It displays the byte-compiled code in a help window in symbolic form, one instruction per line. If the instruction refers to a variable or constant, that is shown, too.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
XEmacs can run Mocklisp files by converting them to Emacs Lisp first. To convert a Mocklisp file, visit it and then type M-x convert-mocklisp-buffer. Then save the resulting buffer of Lisp file in a file whose name ends in ‘.el’ and use the new file as a Lisp library.
You cannot currently byte-compile converted Mocklisp code. The reason is that converted Mocklisp code uses some special Lisp features to deal with Mocklisp’s incompatible ideas of how arguments are evaluated and which values signify “true” or “false”.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Lisp programs intended to be run in Emacs should be edited in Emacs-Lisp mode; this will happen automatically for file names ending in ‘.el’. By contrast, Lisp mode itself should be used for editing Lisp programs intended for other Lisp systems. Emacs-Lisp mode can be selected with the command M-x emacs-lisp-mode.
For testing of Lisp programs to run in Emacs, it is useful to be able to evaluate part of the program as it is found in the Emacs buffer. For example, if you change the text of a Lisp function definition and then evaluate the definition, Emacs installs the change for future calls to the function. Evaluation of Lisp expressions is also useful in any kind of editing task for invoking non-interactive functions (functions that are not commands).
Read a Lisp expression in the minibuffer, evaluate it, and print the
value in the minibuffer (eval-expression
).
Evaluate the Lisp expression before point, and print the value in the
minibuffer (eval-last-sexp
).
Evaluate the defun containing point or after point, and print the value in
the minibuffer (eval-defun
).
Evaluate all the Lisp expressions in the region.
Evaluate all the Lisp expressions in the buffer.
M-<ESC> (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 evaluation is complete,
the current buffer is once again the buffer that was current when
M-<ESC> was typed.
M-<ESC> can easily confuse users, especially on keyboards
with autorepeat, where it can result from holding down the <ESC> key
for too long. Therefore, eval-expression
is normally a disabled
command. Attempting to use this command asks for confirmation and gives
you the option of enabling it; once you enable the command, you are no
longer required to confirm. @xref{Disabling}.
In Emacs-Lisp mode, the key C-M-x is bound to the function
eval-defun
, which parses the defun containing point 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.
The command C-x C-e (eval-last-sexp
) performs a similar job
but is available in all major modes, not just Emacs-Lisp mode. It finds
the sexp before point, reads it as a Lisp expression, evaluates it, and
prints the value in the echo area. It is sometimes useful to type in an
expression and then, with point still after it, type C-x C-e.
If C-M-x or C-x C-e are given a numeric argument, they print the value by inserting it into the current buffer at point, rather than in the echo area. The argument value does not matter.
The most general command for evaluating Lisp expressions from a buffer
is eval-region
. M-x eval-region parses the text of the
region as one or more Lisp expressions, evaluating them one by one.
M-x eval-current-buffer is similar, but it evaluates the entire
buffer. This is a reasonable way to install the contents of a file of
Lisp code that you are just ready to test. After finding and fixing a
bug, use C-M-x on each function that you change, to keep the Lisp
world in step with the source file.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
XEmacs contains a debugger for Lisp programs executing inside it.
This debugger is normally not used; many commands frequently get Lisp
errors when invoked in inappropriate contexts (such as C-f at the
end of the buffer) and it would be unpleasant to enter a special
debugging mode in this case. When you want to make Lisp errors invoke
the debugger, you must set the variable debug-on-error
to
non-nil
. Quitting with C-g is not considered an error, and
debug-on-error
has no effect on the handling of C-g.
However, if you set debug-on-quit
to be non-nil
, C-g will
invoke the debugger. This can be useful for debugging an infinite loop;
type C-g once the loop has had time to reach its steady state.
debug-on-quit
has no effect on errors.
You can make Emacs enter the debugger when a specified function
is called or at a particular place in Lisp code. Use M-x
debug-on-entry with argument fun-name to have Emacs enter the
debugger as soon as fun-name is called. Use
M-x cancel-debug-on-entry to make the function stop entering the
debugger when called. (Redefining the function also does this.) To enter
the debugger from some other place in Lisp code, you must insert the
expression (debug)
there and install the changed code with
C-M-x. See section Evaluating Emacs-Lisp Expressions.
When the debugger is entered, it displays the previously selected buffer in one window and a buffer named ‘*Backtrace*’ in another window. The backtrace buffer contains one line for each level of Lisp function execution currently going on. At the beginning of the buffer is a message describing the reason that the debugger was invoked, for example, an error message if it was invoked due to an error.
The backtrace buffer is read-only and is in Backtrace mode, a special major mode in which letters are defined as debugger commands. The usual Emacs editing commands are available; you can switch windows to examine the buffer that was being edited at the time of the error, and you can switch buffers, visit files, and perform any other editing operations. However, the debugger is a recursive editing level (@pxref{Recursive Edit}); it is a good idea to return to the backtrace buffer and explictly exit the debugger when you don’t want to use it any more. Exiting the debugger kills the backtrace buffer.
The contents of the backtrace buffer show you the functions that are executing and the arguments that were given to them. It also allows you to specify a stack frame by moving point to the line describing that frame. The frame whose line point is on is considered the current frame. Some of the debugger commands operate on the current frame. Debugger commands are mainly used for stepping through code one expression at a time. Here is a list of them:
Exit the debugger and continue execution. In most cases, execution of the program continues as if the debugger had never been entered (aside from the effect of any variables or data structures you may have changed while inside the debugger). This includes entry to the debugger due to function entry or exit, explicit invocation, and quitting or certain errors. Most errors cannot be continued; trying to continue an error usually causes the same error to occur again.
Continue execution, but enter the debugger the next time a Lisp function is called. This allows you to step through the subexpressions of an expression, and see what the subexpressions do and what values they compute.
When you enter the debugger this way, Emacs flags the stack frame for the function call from which you entered. The same function is then called when you exit the frame. To cancel this flag, use u.
Set up to enter the debugger when the current frame is exited. Frames that invoke the debugger on exit are flagged with stars.
Don’t enter the debugger when the current frame is exited. This cancels a b command on a frame.
Read a Lisp expression in the minibuffer, evaluate it, and print the value in the echo area. This is equivalent to the command M-<ESC>, except that e is not normally disabled like M-<ESC>.
Terminate the program being debugged; return to top-level Emacs command execution.
If the debugger was entered due to a C-g but you really want to quit, not to debug, use the q command.
Return a value from the debugger. The value is computed by reading an expression with the minibuffer and evaluating it.
The value returned by the debugger makes a difference when the debugger was invoked due to exit from a Lisp call frame (as requested with b); then the value specified in the r command is used as the value of that frame.
The debugger’s return value also matters with many errors. For example,
wrong-type-argument
errors will use the debugger’s return value
instead of the invalid argument; no-catch
errors will use the
debugger value as a throw tag instead of the tag that was not found.
If an error was signaled by calling the Lisp function signal
,
the debugger’s return value is returned as the value of signal
.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The buffer ‘*scratch*’, which is selected when Emacs starts up, is provided for evaluating Lisp expressions interactively inside Emacs. Both the expressions you evaluate and their output goes in the buffer.
The ‘*scratch*’ buffer’s major mode is Lisp Interaction mode, which
is the same as Emacs-Lisp mode except for one command, <LFD>. In
Emacs-Lisp mode, <LFD> is an indentation command. In Lisp
Interaction mode, <LFD> is bound to eval-print-last-sexp
. This
function reads the Lisp expression before point, evaluates it, and inserts
the value in printed representation before point.
The way to use the ‘*scratch*’ buffer is to insert Lisp expressions at the end, ending each one with <LFD> so that it will be evaluated. The result is a complete typescript of the expressions you have evaluated and their values.
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. M-x lisp-interaction-mode will put any buffer in Lisp Interaction mode.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
To run an inferior Lisp process, type M-x run-lisp. This runs the
program named lisp
, the same program you would run by typing
lisp
as a shell command, with both input and output going through an
Emacs buffer named ‘*lisp*’. In other words, any “terminal output”
from Lisp will go into the buffer, advancing point, and any “terminal
input” for Lisp comes from text in the buffer. To give input to Lisp, go
to the end of the buffer and type the input, terminated by <RET>. The
‘*lisp*’ buffer is in Inferior Lisp mode, which has all the
special characteristics of Lisp mode and Shell mode (@pxref{Shell Mode}).
Use Lisp mode to run the source files of programs in external Lisps. You can select this mode with M-x lisp-mode. It is used automatically for files whose names end in ‘.l’ or ‘.lisp’, as most Lisp systems usually expect.
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
C-M-x. In Lisp mode, this key runs the function lisp-send-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 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. See section Major Modes for Lisp.
[Top] | [Contents] | [Index] | [ ? ] |
This document was generated on December 6, 2024 using texi2html 5.0.
The buttons in the navigation panels have the following meaning:
Button | Name | Go to | From 1.2.3 go to |
---|---|---|---|
[ << ] | FastBack | Beginning of this chapter or previous chapter | 1 |
[ < ] | Back | Previous section in reading order | 1.2.2 |
[ Up ] | Up | Up section | 1.2 |
[ > ] | Forward | Next section in reading order | 1.2.4 |
[ >> ] | FastForward | Next chapter | 2 |
[Top] | Top | Cover (top) of document | |
[Contents] | Contents | Table of contents | |
[Index] | Index | Index | |
[ ? ] | About | About (help) |
where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:
This document was generated on December 6, 2024 using texi2html 5.0.