Mercurial > hg > xemacs-beta
view README.packages @ 853:2b6fa2618f76
[xemacs-hg @ 2002-05-28 08:44:22 by ben]
merge my stderr-proc ws
make-docfile.c: Fix places where we forget to check for EOF.
code-init.el: Don't use CRLF conversion by default on process output. CMD.EXE and
friends work both ways but Cygwin programs don't like the CRs.
code-process.el, multicast.el, process.el: Removed.
Improvements to call-process-internal:
-- allows a buffer to be specified for input and stderr output
-- use it on all systems
-- implement C-g as documented
-- clean up and comment
call-process-region uses new call-process facilities; no temp file.
remove duplicate funs in process.el.
comment exactly how coding systems work and fix various problems.
open-multicast-group now does similar coding-system frobbing to
open-network-stream.
dumped-lisp.el, faces.el, msw-faces.el: Fix some hidden errors due to code not being defined at the right time.
xemacs.mak: Add -DSTRICT.
================================================================
ALLOW SEPARATION OF STDOUT AND STDERR IN PROCESSES
================================================================
Standard output and standard error can be processed separately in
a process. Each can have its own buffer, its own mark in that buffer,
and its filter function. You can specify a separate buffer for stderr
in `start-process' to get things started, or use the new primitives:
set-process-stderr-buffer
process-stderr-buffer
process-stderr-mark
set-process-stderr-filter
process-stderr-filter
Also, process-send-region takes a 4th optional arg, a buffer.
Currently always uses a pipe() under Unix to read the error output.
(#### Would a PTY be better?)
sysdep.h, sysproc.h, unexfreebsd.c, unexsunos4.c, nt.c, emacs.c, callproc.c, symsinit.h, sysdep.c, Makefile.in.in, process-unix.c: Delete callproc.c. Move child_setup() to process-unix.c.
wait_for_termination() now only needed on a few really old systems.
console-msw.h, event-Xt.c, event-msw.c, event-stream.c, event-tty.c, event-unixoid.c, events.h, process-nt.c, process-unix.c, process.c, process.h, procimpl.h: Rewrite the process methods to handle a separate channel for
error input. Create Lstreams for reading in the error channel.
Many process methods need change. In general the changes are
fairly clear as they involve duplicating what's used for reading
the normal stdout and changing for stderr -- although tedious,
as such changes are required throughout the entire process code.
Rewrote the code that reads process output to do two loops, one
for stdout and one for stderr.
gpmevent.c, tooltalk.c: set_process_filter takes an argument for stderr.
================================================================
NEW ERROR-TRAPPING MECHANISM
================================================================
Totally rewrite error trapping code to be unified and support more
features. Basic function is call_trapping_problems(), which lets
you specify, by means of flags, what sorts of problems you want
trapped. these can include
-- quit
-- errors
-- throws past the function
-- creation of "display objects" (e.g. buffers)
-- deletion of already-existing "display objects" (e.g. buffers)
-- modification of already-existing buffers
-- entering the debugger
-- gc
-- errors->warnings (ala suspended errors)
etc. All other error funs rewritten in terms of this one.
Various older mechanisms removed or rewritten.
window.c, insdel.c, console.c, buffer.c, device.c, frame.c: When creating a display object, added call to
note_object_created(), for use with trapping_problems mechanism.
When deleting, call check_allowed_operation() and note_object
deleted().
The trapping-problems code records the objects created since the
call-trapping-problems began. Those objects can be deleted, but
none others (i.e. previously existing ones).
bytecode.c, cmdloop.c: internal_catch takes another arg.
eval.c: Add long comments describing the "five lists" used to maintain
state (backtrace, gcpro, specbind, etc.) in the Lisp engine.
backtrace.h, eval.c: Implement trapping-problems mechanism, eliminate old mechanisms or
redo in terms of new one.
frame.c, gutter.c: Flush out the concept of "critical display section", defined by
the in_display() var. Use an internal_bind() to get it reset,
rather than just doing it at end, because there may be a non-local
exit.
event-msw.c, event-stream.c, console-msw.h, device.c, dialog-msw.c, frame.c, frame.h, intl.c, toolbar.c, menubar-msw.c, redisplay.c, alloc.c, menubar-x.c: Make use of new trapping-errors stuff and rewrite code based on
old mechanisms.
glyphs-widget.c, redisplay.h: Protect calling Lisp in redisplay.
insdel.c: Protect hooks against deleting existing buffers.
frame-msw.c: Use EQ, not EQUAL in hash tables whose keys are just numbers.
Otherwise we run into stickiness in redisplay because
internal_equal() can QUIT.
================================================================
SIGNAL, C-G CHANGES
================================================================
Here we change the way that C-g interacts with event reading. The
idea is that a C-g occurring while we're reading a user event
should be read as C-g, but elsewhere should be a QUIT. The former
code did all sorts of bizarreness -- requiring that no QUIT occurs
anywhere in event-reading code (impossible to enforce given the
stuff called or Lisp code invoked), and having some weird system
involving enqueue/dequeue of a C-g and interaction with Vquit_flag
-- and it didn't work.
Now, we simply enclose all code where we want C-g read as an event
with {begin/end}_dont_check_for_quit(). This completely turns off
the mechanism that checks (and may remove or alter) C-g in the
read-ahead queues, so we just get the C-g normal.
Signal.c documents this very carefully.
cmdloop.c: Correct use of dont_check_for_quit to new scheme, remove old
out-of-date comments.
event-stream.c: Fix C-g handling to actually work.
device-x.c: Disable quit checking when err out.
signal.c: Cleanup. Add large descriptive comment.
process-unix.c, process-nt.c, sysdep.c: Use QUIT instead of REALLY_QUIT.
It's not necessary to use REALLY_QUIT and just confuses the issue.
lisp.h: Comment quit handlers.
================================================================
CONS CHANGES
================================================================
free_cons() now takes a Lisp_Object not the result of XCONS().
car and cdr have been renamed so that they don't get used directly;
go through XCAR(), XCDR() instead.
alloc.c, dired.c, editfns.c, emodules.c, fns.c, glyphs-msw.c, glyphs-x.c, glyphs.c, keymap.c, minibuf.c, search.c, eval.c, lread.c, lisp.h: Correct free_cons calling convention: now takes Lisp_Object,
not Lisp_Cons
chartab.c: Eliminate direct use of ->car, ->cdr, should be black box.
callint.c: Rewrote using EXTERNAL_LIST_LOOP to avoid use of Lisp_Cons.
================================================================
USE INTERNAL-BIND-*
================================================================
eval.c: Cleanups of these funs.
alloc.c, fileio.c, undo.c, specifier.c, text.c, profile.c, lread.c, redisplay.c, menubar-x.c, macros.c: Rewrote to use internal_bind_int() and internal_bind_lisp_object()
in place of whatever varied and cumbersome mechanisms were
formerly there.
================================================================
SPECBIND SANITY
================================================================
backtrace.h: - Improved comments
backtrace.h, bytecode.c, eval.c: Add new mechanism check_specbind_stack_sanity() for sanity
checking code each time the catchlist or specbind stack change.
Removed older prototype of same mechanism.
================================================================
MISC
================================================================
lisp.h, insdel.c, window.c, device.c, console.c, buffer.c: Fleshed out authorship.
device-msw.c: Correct bad Unicode-ization.
print.c: Be more careful when not initialized or in fatal error handling.
search.c: Eliminate running_asynch_code, an FSF holdover.
alloc.c: Added comments about gc-cons-threshold.
dialog-x.c: Use begin_gc_forbidden() around code to build up a widget value
tree, like in menubar-x.c.
gui.c: Use Qunbound not Qnil as the default for
gethash.
lisp-disunion.h, lisp-union.h: Added warnings on use of VOID_TO_LISP().
lisp.h: Use ERROR_CHECK_STRUCTURES to turn on
ERROR_CHECK_TRAPPING_PROBLEMS and ERROR_CHECK_TYPECHECK
lisp.h: Add assert_with_message.
lisp.h: Add macros for gcproing entire arrays. (You could do this before
but it required manual twiddling the gcpro structure.)
lisp.h: Add prototypes for new functions defined elsewhere.
| author | ben |
|---|---|
| date | Tue, 28 May 2002 08:45:36 +0000 |
| parents | 6728e641994e |
| children | 712931b4b71d |
line wrap: on
line source
-*- Outline -*- This file is in Outline mode. It is best viewed under XEmacs. Press C-c C-o (Ctrl+c Ctrl+o) now to see a list of headings. To expand a heading: Put the cursor on the heading and press C-c C-s To collapse a heading: Press C-c C-d For general XEmacs navigation tips: Press C-h t The XEmacs Packages Quick Start Guide ------------------------------------- This text is intended to help you get started installing a new XEmacs and its packages. For more details see the 'Startup Paths' and 'Packages' sections of the XEmacs info manual. * Real Real Quickstart FAQ -------------------------- Q. Do I need to have the packages to compile XEmacs? A. Theoretically, no -- XEmacs will build and install just fine without any packages installed. However, only the most basic editing functions will be available with no packages installed, so installing packages is an essential part of making your installed XEmacs _useful_. Q. I really liked the old way that packages were bundled and do not want to mess with packages at all. A. You can grab all the packages at once like you used to with old XEmacs versions, skip to the 'Sumo Tarball' section below. Q. How do I tell XEmacs where to find the packages? A. Normally, you put the packages under $prefix/lib/packages, where $prefix is specified using the `--prefix' parameter to `configure'. (See `Package hierarchies' below). However, if you have the packages somewhere else (e.g. you're a developer and are compiling the packages yourself, and want your own private copy of everything), use the `--package-path' parameter, something like this: configure --package-path="~/.xemacs::/src/xemacs/site-packages:/src/xemacs/xemacs-packages:/src/xemacs/mule-packages" ... Q. After installing, I want XEmacs to do `foo', but when I invoke it (or click the toolbar button or select the menu item), nothing (or an error) happens, and it used to work. A. See the first FAQ; you may be missing a package that is essential to you. You can either track it down and install it, or install the `Sumo Tarball' (see the second FAQ). * A note of caution ------------------- The XEmacs package system is still in its infancy. Please expect a few minor hurdles on the way. Also neither the interface nor the structure is set in stone. The XEmacs maintainers reserve the right to sacrifice backwards compatibility as quirks are worked out over the coming releases. * Some package theory --------------------- In order to reduce the size and increase the maintainability of XEmacs, the majority of the Elisp packages that came with previous releases have been unbundled. They have been replaced by the package system. Each elisp add-on (or groups of them when they are small) now comes in its own tarball that contains a small search hierarchy. You select just the ones you need. Install them by untarring them into the right place. On startup XEmacs will find them, set up the load path correctly, install autoloads, etc, etc. * Package hierarchies --------------------- On Startup XEmacs looks for packages in so-called package hierarchies. Normally, there are three system wide hierarchies, like this: $prefix/lib/xemacs/xemacs-packages/ Normal packages go here. $prefix/lib/xemacs/mule-packages/ Mule packages go here and are only searched by MULE-enabled XEmacsen. $prefix/lib/xemacs/site-packages/ Local and 3rd party packages go here. This is what you get when you untar the SUMO tarballs under $prefix/lib/xemacs. $prefix is specified using the `--prefix' parameter to `configure', and defaults to `usr/local'. If your packages are located in the above directories, XEmacs will automatically find them at startup; however, if you have your packages somewhere else (e.g. you're a developer and are compiling the packages yourself, and want your own private copy of everything), you can tell XEmacs specifically where to look for the packages by using the `--package-path' parameter to the 'configure' script. Normally, it looks like this: configure --package-path="~/.xemacs::/src/xemacs/site-packages:/src/xemacs/xemacs-packages:/src/xemacs/mule-packages" ... See `configure.usage' for more info about the format of this parameter. * Where to get the packages --------------------------- Packages are available from ftp://ftp.xemacs.org/pub/xemacs/packages and its mirrors. * How to install the packages ----------------------------- There are a few different ways to install packages: 1. Manually, all at once, using the 'Sumo Tarball'. 2. Manually, using individual package tarballs. 3. Automatically, using the package tools from XEmacs. ** Manually, all at once, using the 'Sumo Tarball' -------------------------------------------------- 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, using individual package tarballs ---------------------------------------------- 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 (see 'Upgrading/Removing Packages' below). 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, using the package tools from XEmacs ----------------------------------------------------- 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 resulting buffer, "*Packages*" has brief instructions at the end of the buffer. (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 * After Installation -------------------- New packages can only be used by XEmacs after a restart. * 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 '.../etc/PACKAGES' for further descriptions of the individual packages. * Upgrading/Removing Packages ----------------------------- As 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 belong to the package. M-x package-admin-delete-binary-package RET can be used to remove a package using this file. Note that the interactive package tools included with XEmacs already do this for you. * User Package directories -------------------------- In addition to the system wide packages, each user can have his own packages installed in "~/.xemacs/xemacs-packages". If you want to install packages there using the interactive tools, you need to set 'pui-package-install-dest-dir' to "~/.xemacs/xemacs-packages" * Site lisp/Site start ---------------------- The site-packages hierarchy replaces the old 'site-lisp' directory. XEmacs no longer looks into a 'site-lisp' directly by default. A good place to put 'site-start.el' would be in $prefix/lib/xemacs/site-packages/lisp/ * Finding the right packages ---------------------------- If you want to find out which package contains the functionality you are looking for, use M-x package-get-package-provider, and give it a symbol that is likely to be in that package. For example, if some code you want to use has a (require 'thingatpt) in it: M-x package-get-package-provider RET thingatpt RET which will return something like: (fsf-compat "1.08").