Sync up with r21-4-14-chise-0_21-17.

[chise/xemacs-chise.git] / info / xemacs.info-13

This is ../info/xemacs.info, produced by makeinfo version 4.0b from
xemacs/xemacs.texi.

INFO-DIR-SECTION XEmacs Editor
START-INFO-DIR-ENTRY
* XEmacs: (xemacs).             XEmacs Editor.
END-INFO-DIR-ENTRY

   This file documents the XEmacs editor.

   Copyright (C) 1985, 1986, 1988 Richard M. Stallman.  Copyright (C)
1991, 1992, 1993, 1994 Lucid, Inc.  Copyright (C) 1993, 1994 Sun
Microsystems, Inc.  Copyright (C) 1995 Amdahl Corporation.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "The GNU Manifesto", "Distribution" and "GNU
General Public License" are included exactly as in the original, and
provided that the entire resulting derived work is distributed under the
terms of a permission notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "The GNU Manifesto",
"Distribution" and "GNU General Public License" may be included in a
translation approved by the author instead of in the original English.

\1f
File: xemacs.info,  Node: Lisp Libraries,  Next: Lisp Eval,  Prev: Lisp Modes,  Up: Running

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 (*note Lisp Modes::).

* Menu:

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

\1f
File: xemacs.info,  Node: Loading,  Next: Compiling Libraries,  Prev: Lisp Libraries,  Up: Lisp Libraries

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

\1f
File: xemacs.info,  Node: Compiling Libraries,  Next: Mocklisp,  Prev: Loading,  Up: Lisp Libraries

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.

\1f
File: xemacs.info,  Node: Mocklisp,  Prev: Compiling Libraries,  Up: Lisp Libraries

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

\1f
File: xemacs.info,  Node: Lisp Eval,  Next: Lisp Debug,  Prev: Lisp Libraries,  Up: Running

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-<ESC>'
     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-<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.  *Note 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.

\1f
File: xemacs.info,  Node: Lisp Debug,  Next: Lisp Interaction,  Prev: Lisp Eval,  Up: Running

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'.  *Note 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 (*note
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-<ESC>', except that `e' is not normally disabled like `M-<ESC>'.

`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'.

\1f
File: xemacs.info,  Node: Lisp Interaction,  Next: External Lisp,  Prev: Lisp Debug,  Up: Running

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.

\1f
File: xemacs.info,  Node: External Lisp,  Prev: Lisp Interaction,  Up: Running

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 (*note 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.  *Note Lisp Modes::.

\1f
File: xemacs.info,  Node: Packages,  Next: Basic,  Prev: Startup Paths,  Up: Top

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.

* Menu:

* 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 don't forget to create/edit it.
* Creating Packages::   The basics.
* Available Packages::  A brief directory of packaged LISP.

\1f
File: xemacs.info,  Node: Package Terminology,  Next: Installing Packages,  Up: Packages

Package Terminology:
====================

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

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.

Binary Packages
---------------

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

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.

\1f
File: xemacs.info,  Node: Installing Packages,  Next: Building Packages,  Prev: Package Terminology,  Up: Packages

Installing Packages:
====================

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.

Choosing the Packages You Need
------------------------------

   The *Note 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 *Note (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 *Note Available Packages:: at the time of the XEmacs release.
Packages are also listed on the `Options' menu under:

             Options -> Customize -> Emacs -> Packages

   However, don't select any of these menu picks unless you actually
want to install the given package (and have properly configured your
system to do so).

   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:

             Options -> Manage Packages -> List & 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.

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

   There are three main ways to install packages:

* Menu:

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

\1f
File: xemacs.info,  Node: Sumo,  Next: Manually,  Up: Installing Packages

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.

\1f
File: xemacs.info,  Node: Manually,  Next: Automatically,  Prev: Sumo,  Up: Installing Packages

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 *Note 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

\1f
File: xemacs.info,  Node: Automatically,  Next: Which Packages,  Prev: Manually,  Up: Installing Packages

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.

   Note: The menus in XEmacs 21.2.x and up have changed slightly, so
where I mention "Options -> Manage Packages", substitute "Tools ->
Packages".

  1. Choose a download site.  via menu: Options -> Manages 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: Options -> Manage 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.

\1f
File: xemacs.info,  Node: Which Packages,  Next: Removing Packages,  Prev: Automatically,  Up: Installing 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 *Note Available Packages:: for further descriptions of the
individual packages.

\1f
File: xemacs.info,  Node: Removing Packages,  Prev: Which Packages,  Up: Installing 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-admin-delete-binary-package RET'.

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

\1f
File: xemacs.info,  Node: Building Packages,  Next: Local.rules File,  Prev: Installing Packages,  Up: Packages

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.

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

`GNU cp'

`GNU ginstall'
     (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.'
     *Note Local.rules File::.  And of course, XEmacs 21.0 or higher.

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.

\1f
File: xemacs.info,  Node: Local.rules File,  Next: Creating Packages,  Prev: Building Packages,  Up: Packages

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 = libs/xemacs-base comm/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/mule-base mule/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

\1f
File: xemacs.info,  Node: Creating Packages,  Next: Available Packages,  Prev: Local.rules File,  Up: 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 admistrative grouping.  Current
categories include `comm', `games', `libs', `mule', `oa', `os', `prog',
and `wp'.  *Note Available Packages::, for a list of categories.

   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.