22 Compiling and Testing Programs
*********************************

  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.

* Compilation::        Compiling programs in languages other than Lisp
                        (C, Pascal, etc.)
* Modes: Lisp Modes.   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.
* Debug: Lisp Debug.   Debugging Lisp programs running in Emacs.
* Interaction: Lisp Interaction.  Executing Lisp in an Emacs buffer.
* External Lisp::      Communicating through Emacs with a separate Lisp.

22.1 Running "make", or Compilers Generally
===========================================

  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.

M-x compile
Run a compiler asynchronously under Emacs, with error messages to
`*compilation*' buffer.
M-x grep
Run grep asynchronously under Emacs, with matching lines
listed in the buffer named `*compilation*'.
M-x kill-compilation
Kill the process made by the M-x compile command.
M-x kill-grep
Kill the running compilation or grep subprocess.
C-x `
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 (see 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 = ...

22.2 Major Modes for Lisp
=========================

  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.

Emacs-Lisp mode
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 Lisp Libraries.
Lisp Interaction mode
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 Lisp Interaction.
Lisp mode
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 External Lisp.
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
(see Shell Mode).
Scheme mode
Like Lisp mode but for Scheme programs.
Inferior Scheme mode
The mode for an interactive session with an inferior Scheme process.

22.3 Libraries of Lisp Code for Emacs
=====================================

  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 Lisp Modes).

* Loading::		Loading libraries of Lisp code into Emacs for use.
* Compiling Libraries:: Compiling a library makes it load and run faster.
* Mocklisp::		Converting Mocklisp to Lisp so XEmacs can run it.

22.3.1 Loading Libraries
------------------------

M-x load-file file
Load the file file of Lisp code.
M-x load-library library
Load the library named library.
M-x locate-library library &optional nosuffix
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.

22.3.2 Compiling Libraries
--------------------------

  Emacs Lisp code can be compiled into byte-code which loads faster,
takes up less space when loaded, and executes faster.

M-x batch-byte-compile
Run byte-compile-file on the files remaining on the command line.
M-x byte-compile-buffer &optional buffer
Byte-compile and evaluate contents of buffer (default is current 
buffer).
M-x byte-compile-file
Compile a file of Lisp code named filename into a file of byte code.
M-x byte-compile-and-load-file filename
Compile a file of Lisp code named filename into a file of byte
code and load it.
M-x byte-recompile-directory directory
Recompile every `.el' file in directory that needs recompilation.
M-x disassemble
Print disassembled code for object on (optional) stream.
M-x make-obsolete function new
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.

22.3.3 Converting Mocklisp to Lisp
----------------------------------

  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".

22.4 Evaluating Emacs-Lisp Expressions
======================================

  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).

M-:
Read a Lisp expression in the minibuffer, evaluate it, and print the
value in the minibuffer (eval-expression).
C-x C-e
Evaluate the Lisp expression before point, and print the value in the
minibuffer (eval-last-sexp).
C-M-x
Evaluate the defun containing point or after point, and print the value in
the minibuffer (eval-defun).
M-x eval-region
Evaluate all the Lisp expressions in the region.
M-x eval-current-buffer
Evaluate all the Lisp expressions in the buffer.

  M-: (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-: was typed.

  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.

22.5 The Emacs-Lisp Debugger
============================

  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 Lisp Eval.

  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
(see Recursive Edit); it is a good idea to return to the backtrace
buffer and explicitly 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:

c
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.
d
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.
b
Set up to enter the debugger when the current frame is exited.  Frames
that invoke the debugger on exit are flagged with stars.
u
Don't enter the debugger when the current frame is exited.  This
cancels a b command on a frame.
e
Read a Lisp expression in the minibuffer, evaluate it, and print the
value in the echo area.  This is equivalent to the command M-:.
q
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.
r
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.

22.6 Lisp Interaction Buffers
=============================

  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.

22.7 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.

  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 (see 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 Lisp Modes.

22.8 Packages
=============

The XEmacs 21 distribution comes only with a very basic set of
built-in modes and packages.  Most of the packages that were part of
the distribution of earlier versions of XEmacs are now available
separately.  The installer as well as the user can choose which
packages to install; the actual installation process is easy.
This gives an installer the ability to tailor an XEmacs installation for
local needs with safe removal of unnecessary code.

* Package Terminology:: Understanding different kinds of packages.
* Installing Packages:: How to install packages.
* Building Packages::   Building packages from CVS sources.
* Local.rules File::    This is an important file that you must create.
* Creating Packages::   The basics.
* Available Packages::  A brief directory of packaged LISP.

Package Terminology:
====================
22.8.1 Package Flavors
----------------------

There are two main flavors of packages.

* Regular Packages
A regular package is one in which multiple files are involved and one
may not in general safely remove any of them.

* Single-File Packages
A single-file package is an aggregate collection of thematically
related but otherwise independent lisp files.  These files are bundled 
together for download convenience and individual files may be deleted at
will without any loss of functionality.  However, we would recommend
that you follow this rule of thumb: "When in doubt, don't delete".

22.8.2 Package Distributions
----------------------------
XEmacs Lisp packages are distributed in two ways, depending on the
intended use.  Binary Packages are for installers and end-users that can
be installed directly into an XEmacs package directory.  Source Packages
are for developers and include all files necessary for rebuilding
bytecompiled lisp and creating tarballs for distribution.

22.8.3 Binary Packages
----------------------
Binary packages may be installed directly into an XEmacs package
hierarchy.

22.8.4 Source Packages
----------------------
Source packages contain all of the Package author's (where appropriate
in regular packages) source code plus all of the files necessary to
build distribution tarballs (Unix Tar format files, gzipped for space
savings).

Currently, source packages are only available via CVS.  See
<http://cvs.xemacs.org/> for details.
Installing Packages:
====================
22.8.5 Getting Started
----------------------

When you first download XEmacs 21, you will usually first grab the
core distribution,
a file called
`xemacs-21.x.x.tar.gz'. (Replace the 21.x.x by the current version
number.)  The core distribution contains the sources of XEmacs and a
minimal set of Emacs Lisp files, which are in the subdirectory named
`lisp'.  This subdirectory used to contain all Emacs Lisp files
distributed with XEmacs.  Now, to conserve disk space, most
non-essential packages were made optional.

22.8.6 Choosing the Packages You Need
-------------------------------------
The Available Packages can currently be found in the same ftp directory
where you grabbed the core distribution from, and are located in the
subdirectory `packages'.  Package file names follow
the naming convention `<package-name>-<version>-pkg.tar.gz'.

If you have (EFS), packages can be installed over the network.
Alternatively, if you have copies of the packages locally, you can
install packages from a local disk or CDROM.

The file `etc/PACKAGES' in the core distribution contains a list of
the Available Packages at the time of the XEmacs release.

You can also get a list of available packages, and whether or not they
are installed, using the visual package browser and installer.  You can
access it via the menus:

        Tools -> Packages -> List and Install

Or, you can get to it via the keyboard:

M-x pui-list-packages

Hint to system administrators of multi-user systems: it might be a good
idea to install all packages and not interfere with the wishes of your
users.

If you can't find which package provides the feature you require, try
using the package-get-package-provider function. Eg., if you know 
that you need thingatpt, type:

M-x package-get-package-provider RET thingatpt

which will return something like (fsf-compat "1.08"). You can the use
one of the methods above for installing the package you want.

22.8.7 XEmacs and Installing Packages
-------------------------------------

There are three main ways to install packages:

* Sumo::              All at once, using the 'Sumo Tarball'.
* Manually::          Using individual package tarballs.
* Automatically::     Using the package tools from XEmacs.
* Which Packages::    Which packages to install.
* Removing Packages:: Removing packages.

But regardless of the method you use to install packages, they can only
be used by XEmacs after a restart.

Sumo
----
Installing the Sumo Packages:
=============================
Those with little time, cheap connections and plenty of disk space can
install all the packages at once using the sumo tarballs.
Download the file: `xemacs-sumo.tar.gz'

For an XEmacs compiled with Mule you also need: `xemacs-mule-sumo.tar.gz'

N.B. They are called 'Sumo Tarballs' for good reason. They are
currently about 19MB and 4.5MB (gzipped) respectively.

Install them by:

cd $prefix/lib/xemacs ; gunzip -c <tarballname> | tar xvf - RET

Or, if you have GNU tar:

cd $prefix/lib/xemacs ; tar zxvf /path/to/<tarballname> RET

As the Sumo tarballs are not regenerated as often as the individual
packages, it is recommended that you use the automatic package tools
afterwards to pick up any recent updates.

Manually
--------
Manual Package Installation:
============================
Fetch the packages from the FTP site, CD-ROM whatever. The filenames
have the form `name-<version>-pkg.tar.gz' and are gzipped tar files. For
a fresh install it is sufficient to untar the file at the top of the
package hierarchy. 

Note: If you are upgrading packages already installed, it's best to
remove the old package first Removing Packages.

For example if we are installing the `xemacs-base'
package (version 1.48):

   mkdir $prefix/lib/xemacs/xemacs-packages RET # if it does not exist yet
   cd $prefix/lib/xemacs/xemacs-packages RET
   gunzip -c /path/to/xemacs-base-1.48-pkg.tar.gz | tar xvf - RET

Or if you have GNU tar, the last step can be:

   tar zxvf /path/to/xemacs-base-1.48-pkg.tar.gz RET

For MULE related packages, it is best to untar into the mule-packages
hierarchy, i.e. for the `mule-base' package, version 1.37:

   mkdir $prefix/lib/xemacs/mule-packages RET # if it does not exist yet
   cd $prefix/lib/xemacs/mule-packages RET
   gunzip -c /path/to/mule-base-1.37-pkg.tar.gz | tar xvf - RET

Or if you have GNU tar, the last step can be:

   tar zxvf /path/to/mule-base-1.37-pkg.tar.gz RET

Automatically
-------------
Automatic Package Installation:
===============================
XEmacs comes with some tools to make the periodic updating and
installing easier. It will notice if new packages or versions are
available and will fetch them from the FTP site.

Unfortunately this requires that a few packages are already in place.
You will have to install them by hand as above or use a SUMO tarball.
This requirement will hopefully go away in the future. The packages
you need are:

   efs          - To fetch the files from the FTP site or mirrors.
   xemacs-base  - Needed by efs.

and optionally:

   mule-base    - Needed if you want to use XEmacs with MULE.

After installing these by hand, fire up XEmacs and follow these
steps.

1. Choose a download site.
via menu: Tools -> Packages -> Add Download Site 
via keyb: M-x customize-variable RET package-get-remote RET
(put in the details of remote host and directory)

If the package tarballs _AND_ the package-index file are in a
local directory, you can: M-x pui-add-install-directory RET

2. Obtain a list of packages and display the list in a buffer named
`*Packages*'.
menu: Tools -> Packages -> List & Install
keyb: M-x pui-list-packages RET

XEmacs will now connect to the remote site and download the
latest package-index file.  If you see an error about the
package-index entries not being PGP signed, you can safely
ignore this because PGP has not been integrated into the XEmacs
package tools yet.

The visual package browser will then display a list of all packages.
Help information will be displayed at the very bottom of the buffer; you
may have to scroll down to see it.  You can also press ? to get
the same help.  From this buffer, you can tell the package status by the
character in the first column:

-
The package has not been installed.
*
The package has been installed, but a newer version is available.  The
current version is out-of-date.
+
The package has been marked for installation/update.

If there is no character in the first column, the package has been
installed and is up to date.

From here, you can select or unselect packages for installation using
the <RET> key, the Mouse-2 button or selecting "Select" from
the (Popup) Menu.
Once you've finished selecting the packages, you can
press the x key (or use the menu) to actually install the
packages. Note that you will have to restart XEmacs for XEmacs to
recognize any new packages.

Key summary:

?
Display simple help.
<RET>
<Mouse-2>
Toggle between selecting and unselecting a package for installation.
x
Install selected packages.
<SPC>
View, in the minibuffer, additional information about the package, such
as the package date (not the build date) and the package author.  Moving 
the mouse over a package name will also do the same thing.
v
Toggle between verbose and non-verbose package display.
g
Refresh the package display.
q
Kill the package buffer.

Moving the mouse over a package will also cause additional information
about the package to be displayed in the minibuffer.


3. Choose the packages you wish to install.
mouse: Click button 2 on the package name.
 keyb: RET on the package name

4. Make sure you have everything you need.
menu: Packages -> Add Required
keyb: r

XEmacs will now search for packages that are required by the
ones that you have chosen to install and offer to select
those packages also.

For novices and gurus alike, this step can save your bacon.
It's easy to forget to install a critical package.

5. Download and install the packages.
menu: Packages -> Install/Remove Selected
keyb: x

You can also install packages using a semi-manual interface:

M-x package-get-all <return>

Enter the name of the package (e.g., prog-modes), and XEmacs
will search for the latest version and install it and any packages that
it depends upon.

Which Packages
--------------
Which Packages to Install:
==========================
This is difficult to say. When in doubt install a package. If you
administrate a big site it might be a good idea to just install
everything. A good minimal set of packages for XEmacs-latin1 would be

xemacs-base, xemacs-devel, c-support, cc-mode, debug, dired, efs,
edit-utils, fsf-compat, mail-lib, net-utils, os-utils, prog-modes,
text-modes, time

If you are using the XEmacs package tools, don't forget to do:

	Packages -> Add Required

To make sure you have everything that the packages you have chosen to
install need.

See also Available Packages for further descriptions of the individual
packages.

Removing Packages
-----------------
Removing Packages:
==================
Because the exact files and their locations contained in a package may
change it is recommended to remove a package first before installing a
new version. In order to facilitate removal each package contains an
`pgkinfo/MANIFEST.pkgname' file which list all the files belonging
to the package. 

No need to panic, you don't have to go through the
`pkinfo/MANIFEST.pkgname' and manually delete the files.  Instead, use
M-x package-get-delete-package RET.

Note that the interactive package tools included with XEmacs already do
this for you.

Building Packages:
==================
Currently, source packages are only available via anonymous CVS.  See
<http://cvs.xemacs.org/> for details of checking out the
`xemacs-packages' module.

22.8.8 Prerequisites for Building Source Packages
-------------------------------------------------

GNU cp
GNU install
(or a BSD compatible install program).
GNU make
(3.75 or later preferred).
makeinfo
(1.68 from texinfo-3.11 or later required).
GNU tar
(or equivalent).
GNU gzip
(or equivalent).
A properly configured `Local.rules' file.
Local.rules File.
And of course, XEmacs 21.0 or higher.

22.8.9 What You Can Do With Source Packages
-------------------------------------------

The packages CVS sources are most useful for creating XEmacs package
tarballs for installation into your own XEmacs installations or for
distributing to others.

Supported operations from `make' are:

all
Bytecompile all files, build and bytecompile byproduct files like
`auto-autoloads.el' and `custom-load.el'.  Create info version
of TeXinfo documentation if present.

bindist
Does a make all as well as create a binary package tarball in the
staging directory.

install
Bytecompile all files, build and bytecompile byproduct files like
`auto-autoloads.el' and `custom-load.el'.  Create info version
of TeXinfo documentation if present.  And install everything into the
staging directory.

srckit
Usually aliased to srckit-std.  This does a make
distclean and creates a package source tarball in the staging
directory.  This is generally only of use for package maintainers.

binkit
May be aliased to binkit-sourceonly, binkit-sourceinfo,
binkit-sourcedata, or
binkit-sourcedatainfo. sourceonly indicates there is
nothing to install in a data directory or info directory.
sourceinfo indicates that source and info files are to be
installed.  sourcedata indicates that source and etc (data) files
are to be installed.  sourcedatainfo indicates source, etc
(data), and info files are to be installed.  A few packages have needs
beyond the basic templates so this is not yet complete.

dist
Runs the rules srckit followed by binkit.  This is
primarily of use by XEmacs maintainers producing files for distribution.

clean
Remove all built files except `auto-autoloads.el' and `custom-load.el'.

distclean
Remove all created files.

Local.rules File
----------------
The Local.rules File:
=====================
This file is used when building and installing packages from source.  In
the top level of the CVS module, `xemacs-packages', contains the
file, `Local.rules.template'.  Simply copy that to
`Local.rules' and edit it to suit your needs.

These are the variables in 'Local.rules' that you will need to
address. 

symlink =
Set this to 't' if you want to do a "run in place".
Setting this doesn't work well with 'make bindist'

XEMACS_PACKAGES =
This is where you set the normal packages that you
want to install. eg:
      XEMACS_PACKAGES = xemacs-packages/xemacs-base xemacs-packages/bbdb

XEMACS_STAGING = ${XEMACS_PACKAGES_BASE}/../Packages
Set this to where you want normal packages to be
installed to.

PACKAGE_INDEX = package-index
If you want the package-index file to have a different
name, change this.

BUILD_WITHOUT_MULE =
Building from CVS defaults to building the Mule
packages.  Set this to 't' if you don't want/have Mule

MULE_PACKAGES =
Same as for 'XEMACS_PACKAGES' except you list the Mule
packages you want to install here. eg:
      MULE_PACKAGES = mule-packages/mule-base mule-packages/skk

MULE_STAGING = ${XEMACS_PACKAGES_BASE}/../Mule-Packages
Set this to where you want Mule packages installed
to.  Note:  'make bindist' does not use this variable.

XEMACS = xemacs
If your XEmacs isn't in your path, change this.

XEMACS_NATIVE_NT =
Set this to 't' if you are building on WinNT.

INSTALL = install -c
The path to your BSD compatible install program.

TAR = tar
The path to your tar program

BZIP2 =
If you want bzip2 tarballs, set this.

MAKEINFO = makeinfo
The path to your makeinfo program


Creating Packages
-----------------
Creating Packages:
==================
Creating a package from an existing Lisp library is not very difficult.

In addition to the Lisp libraries themselves, you need a
`package-info.in' file and a simple `Makefile'.  The rest is
done by `XEmacs.rules', part of the packaging system
infrastructure.

`package-info.in' contains a single Lisp form like this:

(name                               ; your package's name
  (standards-version 1.1
   version VERSION
   author-version AUTHOR_VERSION
   date DATE
   build-date BUILD_DATE
   maintainer MAINTAINER
   distribution xemacs              ; change to "mule" if MULE is needed
   priority high
   category CATEGORY
   dump nil
   description "description"        ; a one-line description string
   filename FILENAME
   md5sum MD5SUM
   size SIZE
   provides (feature1 feature2)     ; one for every `provides' form
   requires (REQUIRES)
   type regular
))

You must fill in the four commented lines.  The value of name is
the name of your package as an unquoted symbol.  Normally it is the name
of the main Lisp file or principal feature provided.  The allowed values
for distribution are xemacs and mule.  Write them as
unquoted symbols.  The description is a quoted Lisp string; use
the usual conventions.  The value for provides is a list of
feature symbols (written unquoted).  All of the features provided by
libraries in your package should be elements of this list.  Implementing
an automatic method for generating the `provides' line is
desirable, but as yet undone.

The variables in upper-case are references to variables set in the
`Makefile' or automatically generated.  Do not change them; they
are automatically filled in by the build process.

The remaining lines refer to implementation constants
(standards-version), or features that are unimplemented or have
been removed (priority and dump).  The type line is
not normally relevant to external maintainers; the alternate value is
single-file, which refers to packages consed up out of a number
of single-file libraries that are more or less thematically related.  An
example is prog-modes.  Single-file packages are basically for
administrative convenience, and new packages should generally be created
as regular packages.

The `Makefile' is quite stylized.  The idea is similar to an
`Imakefile' or an automake file: the complexity is hidden in
generic rules files, in this case the `XEmacs.rules' include file
in the top directory of the packages hierarchy.  Although a number of
facilities are available for complex libraries, most simple packages'
`Makefile's contain a copyright notice, a few variable definitions,
an include for `XEmacs.rules', and a couple of standard targets.

The first few make variables defined are VERSION,
AUTHOR_VERSION, MAINTAINER, PACKAGE,
PKG_TYPE, REQUIRES, and CATEGORY.  All but one were
described in the description of `package-info.in'.  The last is an
administrative grouping.  Current categories include standard,
and mule.

Next, define the variable ELCS.  This contains the list of the
byte-compiled Lisp files used by the package.  These files and their
`.el' versions will be included in the binary package.  If there
are other files (such as extra Lisp sources or an upstream
`Makefile') that are normally placed in the installed Lisp
directory, but not byte-compiled, they can be listed as the value of
EXTRA_SOURCES.

The include is simply
include ../../XEmacs.rules

The standard targets follow.  These are

all:: $(ELCS) auto-autoloads.elc

srckit: srckit-alias

binkit: binkit-alias

Other targets (such as Texinfo sources) may need to be added as
dependencies for the all target.  Dependencies for srckit
and binkit (that is, values for srckit-alias and
binkit-alias) are defined in `XEmacs.rules'.  The most useful
of these values are given in the following table.

srckit-alias
Usually set to srckit-std.

binkit-alias
May be set to binkit-sourceonly, binkit-sourceinfo,
binkit-sourcedata, or
binkit-sourcedatainfo.  sourceonly indicates there is
nothing to install in a data directory or info directory.
sourceinfo indicates that source and info files are to be
installed.  sourcedata indicates that source and etc (data) files
are to be installed.  sourcedatainfo indicates source, etc
(data), and info files are to be installed.

Data files include things like pixmaps for a package-specific toolbar,
and are normally installed in `etc/PACKAGE_NAME'.  A few
packages have needs beyond the basic templates.  See `XEmacs.rules'
or a future revision of this manual for details.

Available Packages:
===================
This section lists the Lisp packages that are currently available from
xemacs.org and it's mirrors.  If a particular package that you are
looking for isn't here, please send a message to the
XEmacs Beta list <mailto:xemacs-beta@xemacs.org>.

This data is up to date as of September 22, 2002.

22.8.10 Normal Packages
-----------------------
A very broad selection of elisp packages.

`Sun'
Support for Sparcworks.

`ada'
Ada language support.

`apel'
A Portable Emacs Library.  Used by XEmacs MIME support.

`auctex'
Basic TeX/LaTeX support.

`bbdb'
The Big Brother Data Base: a rolodex-like database program.

`build'
Build XEmacs using custom widgets.

`c-support'
Basic single-file add-ons for editing C code.

`calc'
Emacs calculator.

`calendar'
Calendar and diary support.

`cc-mode'
C, C++ and Java language support.

`clearcase'
Support for the Clearcase version control system.

`cookie'
"Fortune cookie"-style messages. Includes Spook (suspicious phrases) 
and Yow (Zippy quotes).

`crisp'
Crisp/Brief emulation.

`debug'
GUD, gdb, dbx debugging support.

`dictionary'
Interface to RFC2229 dictionary servers.

`dired'
The DIRectory EDitor is for manipulating, and running commands on
files in a directory.

`docbookide'
DocBook editing support.

`ecrypto'
Crypto functionality in Emacs Lisp.

`edebug'
A Lisp debugger.

`ediff'
Interface over patch.

`edit-utils'
Single file lisp packages for various XEmacs goodies.  Load this and
weed out the junk you don't want.

`edt'
DEC EDIT/EDT emulation.

`efs'
Treat files on remote systems the same as local files.

`eieio'
Enhanced Implementation of Emacs Interpreted Objects.

`elib'
Portable Emacs Lisp utilities library.

`emerge'
Another interface over patch.

`eshell'
Command shell implemented entirely in Emacs Lisp.

`ess'
ESS: Emacs Speaks Statistics.

`eterm'
Terminal emulator.

`eudc'
Emacs Unified Directory Client (LDAP, PH).

`footnote'
Footnoting in mail message editing modes.

`forms'
Forms editing support (obsolete, use the built-in Widget instead).

`fortran-modes'
Fortran language support.

`frame-icon'
Provide a WM icon based on major mode.

`fsf-compat'
GNU Emacs compatibility files.

`games'
Tetris, Sokoban, and Snake.

`gnats'
XEmacs bug reports.

`gnus'
The Gnus Newsreader and Mailreader.

`haskell-mode'
Haskell language support.

`hm--html-menus'
HTML editing.

`ibuffer'
Advanced replacement for buffer-menu.

`idlwave'
Editing and Shell mode for the Interactive Data Language.

`igrep'
Enhanced front-end for Grep.

`ilisp'
Front-end for interacting with Inferior Lisp (external lisps).

`ispell'
Spell-checking with ispell.

`jde'
Java language and development support.

`liece'
IRC (Internet Relay Chat) client for Emacs.

`mail-lib'
Fundamental lisp files for providing email support.

`mailcrypt'
Support for messaging encryption with PGP.

`mew'
Messaging in an Emacs World; a MIME-based email program.

`mh-e'
Front end support for MH.

`mine'
Elisp implementation of the game 'Minehunt'.

`misc-games'
Other amusements and diversions.

`mmm-mode'
Support for Multiple Major Modes within a single buffer.

`net-utils'
Miscellaneous Networking Utilities.  This is a single-file package and 
files may be deleted at will.

`os-utils'
Miscellaneous single-file O/S utilities, for printing, archiving,
compression, remote shells, etc.

`ocaml'
Objective Caml language support.

`pc'
PC style interface emulation.

`pcl-cvs'
CVS frontend.

`pcomplete'
Provides programmatic completion.

`perl-modes'
Perl language support.

`prog-modes'
Miscellaneous single-file lisp files for various programming languages.

`ps-print'
Print buffers to PostScript printers.

`psgml'
Validated HTML/SGML editing.

`psgml-dtds'
A collection of DTDs for psgml.  Note that this package is deprecated
and will be removed in the future, most likely Q2/2003.  Instead of using
this, you should install needed DTDs yourself.

`python-modes'
Python language support.

`reftex'
Emacs support for LaTeX cross-references, citations.

`rmail'
An obsolete Emacs mailer.  If you do not already use it don't start.

`ruby-modes'
Ruby language support.

`sasl'
Simple Authentication and Security Layer (SASL) library.

`scheme'
Front-end support for Inferior Scheme.

`semantic'
Semantic bovinator.

`sgml'
SGML/Linuxdoc-SGML editing.

`sh-script'
Support for editing shell scripts.

`sieve'
Manage Sieve email filtering scripts.

`slider'
User interface tool.

`sml-mode'
Standard ML editing support.

`sounds-au'
XEmacs Sun sound files.

`sounds-wav'
XEmacs Microsoft sound files.

`speedbar'
Provides a separate frame with convenient references.

`strokes'
Mouse enhancement utility.

`supercite'
An Emacs citation tool.  Useful with all Emacs Mailers and Newsreaders.

`texinfo'
XEmacs TeXinfo support.

`text-modes'
Various single file lisp packages for editing text files.

`textools'
Single-file TeX support.

`time'
Display time & date on the modeline.

`tm'
Emacs MIME support. Not needed for Gnus >= 5.8.0

`tooltalk'
Support for building with Tooltalk.

`tpu'
DEC EDIT/TPU support.

`tramp'
Remote shell-based file editing.  This is similar to EFS or Ange-FTP,
but works with rsh/ssh and rcp/scp.

`vc'
Version Control for Free systems.

`vc-cc'
Version Control for ClearCase.  This package will shortly be
replaced with clearcase.el

`vhdl'
Support for VHDL.

`view-process'
A Unix process browsing tool.

`viper'
VI emulation support.

`vm'
An Emacs mailer.

`w3'
A Web browser.

`xemacs-base'
Fundamental XEmacs support.  Install this unless you wish a totally
naked XEmacs.

`xemacs-devel'
XEmacs Lisp developer support.  This package contains utilities for
supporting Lisp development.  It is a single-file package so it may be 
tailored.

`xslide'
XSL editing support.

`xslt-process'
A minor mode for (X)Emacs which allows running an XSLT processor on a
buffer.

`zenirc'
ZENIRC IRC Client.

22.8.11 Mule Support (mule)
---------------------------

MULti-lingual Enhancement.  Support for world scripts such as
Latin, Arabic, Cyrillic, Chinese, Japanese, Greek, Hebrew etc.
To use these packages your XEmacs must be compiled with Mule
support.

`edict'
Lisp Interface to EDICT, Kanji Dictionary.

`egg-its'
Wnn (4.2 and 6) support.  SJ3 support.  Must be installed prior to
XEmacs build.

`latin-unity'
Unify character sets in a buffer. When characters belong to disjoint
character sets, this attempts to translate the characters so
that they belong to one character set. If the buffer coding system is
not sufficient, this suggests different coding systems.

`leim'
Quail.  Used for everything other than English and Japanese.

`locale'
Used for localized menubars (French and Japanese) and localized splash
screens (Japanese).

`lookup'
Dictionary support. (This isn't an English dictionary program)

`mule-base'
Basic Mule support.  Must be installed prior to building with Mule.

`mule-ucs'
Extended coding systems (including Unicode) for XEmacs.

`skk'
Another Japanese Language Input Method.  Can be used without a
separate process running as a dictionary server.


