Mercurial > hg > xemacs-beta
view README.packages @ 617:af57a77cbc92
[xemacs-hg @ 2001-06-18 07:09:50 by ben]
---------------------------------------------------------------
DOCUMENTATION FIXES:
---------------------------------------------------------------
eval.c: Correct documentation.
elhash.c: Doc correction.
---------------------------------------------------------------
LISP OBJECT CLEANUP:
---------------------------------------------------------------
bytecode.h, buffer.h, casetab.h, chartab.h, console-msw.h, console.h, database.c, device.h, eldap.h, elhash.h, events.h, extents.h, faces.h, file-coding.h, frame.h, glyphs.h, gui-x.h, gui.h, keymap.h, lisp-disunion.h, lisp-union.h, lisp.h, lrecord.h, lstream.h, mule-charset.h, objects.h, opaque.h, postgresql.h, process.h, rangetab.h, specifier.h, toolbar.h, tooltalk.h, ui-gtk.h: Add wrap_* to all objects (it was already there for a few of them)
-- an expression to encapsulate a pointer into a Lisp object,
rather than the inconvenient XSET*. "wrap" was chosen because
"make" as in make_int(), make_char() is not appropriate. (It
implies allocation. The issue does not exist for ints and chars
because they are not allocated.)
Full error checking has been added to these expressions. When
used without error checking, non-union build, use of these
expressions will incur no loss of efficiency. (In fact, XSET* is
now defined in terms of wrap_* in a non-union build.) In a union
build, you will also get no loss of efficiency provided that you
have a decent optimizing compiler, and a compiler that either
understands inlines or automatically inlines those particular
functions. (And since people don't normally do their production
builds on union, it doesn't matter.)
Update the sample Lisp object definition in lrecord.h accordingly.
dumper.c: Fix places in dumper that referenced wrap_object to reference
its new name, wrap_pointer_1.
buffer.c, bufslots.h, conslots.h, console.c, console.h, devslots.h, device.c, device.h, frame.c, frame.h, frameslots.h, window.c, window.h, winslots.h: -- Extract out the Lisp objects of `struct device' into devslots.h,
just like for the other structures.
-- Extract out the remaining (not copied into the window config)
Lisp objects in `struct window' into winslots.h; use different
macros (WINDOW_SLOT vs. WINDOW_SAVED_SLOT) to differentiate them.
-- Eliminate the `dead' flag of `struct frame', since it
duplicates information already available in `framemeths', and fix
FRAME_LIVE_P accordingly. (Devices and consoles already work this
way.)
-- In *slots.h, switch to system where MARKED_SLOT is automatically
undef'd at the end of the file. (Follows what winslots.h already
does.)
-- Update the comments at the beginning of *slots.h to be accurate.
-- When making any of the above objects dead, zero it out entirely
and reset all Lisp object slots to Qnil. (We were already doing
this somewhat, but not consistently.) This (1) Eliminates the
possibility of extra objects hanging around that ought to be
GC'd, (2) Causes an immediate crash if anyone tries to access a
structure in one of these objects, (3) Ensures consistent behavior
wrt dead objects.
dialog-msw.c: Use internal_object_printer, since this object should not escape.
---------------------------------------------------------------
FIXING A CRASH THAT I HIT ONCE (AND A RELATED BAD BEHAVIOR):
---------------------------------------------------------------
eval.c: Fix up some comments about the FSF implementation.
Fix two nasty bugs:
(1) condition_case_unwind frees the conses sitting in the
catch->tag slot too quickly, resulting in a crash that I hit.
(2) catches need to be unwound one at a time when calling
unwind-protect code, rather than all at once at the end; otherwise,
incorrect behavior can result. (A comment shows exactly how.)
backtrace.h: Improve comment about FSF differences in the handler stack.
---------------------------------------------------------------
FIXING A CRASH THAT I REPEATEDLY HIT WHEN USING THE MOUSE WHEEL
UNDER MSWINDOWS:
---------------------------------------------------------------
Basic idea: My crash is due either to a dead, non-marked,
GC-collected frame inside of a window mirror, or a prematurely
freed window mirror. We need to mark the Lisp objects inside of
window mirrors. Tracking the lifespan of window mirrors and
scrollbar instances is extremely hard, and there may well be
lurking bugs where such objects are freed too soon. The only safe
way to fix these problems (and it fixes both problems at once) is
to make both of these structures Lisp objects.
lrecord.h, emacs.c, inline.c, scrollbar-gtk.c, scrollbar-msw.c, scrollbar-x.c, scrollbar.c, scrollbar.h, symsinit.h: Make scrollbar instances actual Lisp objects. Mark the window
mirrors in them. inline.c needs to know about scrollbar.h now.
Record the new type in lrecord.h. Fix up scrollbar-*.c
appropriately. Create a hash table in scrollbar-msw.c so that the
scrollbar instances stored in scrollbar HWND's are properly
GC-protected. Create complex_vars_of_scrollbar_mswindows() to
create the hash table at startup, and call it from emacs.c. Don't
store the scrollbar instance as a property of the GTK scrollbar,
as it's not used and if we did this, we'd have to separately
GC-protect it in a hash table, like in MS Windows.
lrecord.h, frame.h, frame.c, frameslots.h, redisplay.c, window.c, window.h: Move mark_window_mirror from redisplay.c to window.c. Make window
mirrors actual Lisp objects. Tell lrecord.h about them. Change
the window mirror member of struct frame from a pointer to a Lisp
object, and add XWINDOW_MIRROR in appropriate places. Mark the
scrollbar instances in the window mirror.
redisplay.c, redisplay.h, alloc.c: Delete mark_redisplay. Don't call mark_redisplay. We now mark
frame-specific structures in mark_frame.
NOTE: I also deleted an extremely questionable call to
update_frame_window_mirrors(). It was extremely questionable
before, and now totally impossible, since it will create
Lisp objects during redisplay.
frame.c: Mark the scrollbar instances, which are now Lisp objects.
Call mark_gutter() here, not in mark_redisplay().
gutter.c: Update comments about correct marking.
---------------------------------------------------------------
ISSUES BROUGHT UP BY MARTIN:
---------------------------------------------------------------
buffer.h: Put back these macros the way Steve T and I think they ought to be.
I already explained in a previous changelog entry why I think these
macros should be the way I'd defined them. Once again:
We fix these macros so they don't care about the type of their
lvalues. The non-C-string equivalents of these already function
in the same way, and it's correct because it should be OK to pass
in a CBufbyte *, a BufByte *, a Char_Binary *, an UChar_Binary *,
etc. The whole reason for these different types is to work around
errors caused by signed-vs-unsigned non-matching types. Any
possible error that might be caught in a DFC macro would also be
caught wherever the argument is used elsewhere. So creating
multiple macro versions would add no useful error-checking and
just further complicate an already complicated area.
As for Martin's "ANSI aliasing" bug, XEmacs is not ANSI-aliasing
clean and probably never will be. Unless the board agrees to
change XEmacs in this way (and we really don't want to go down
that road), this is not a bug.
sound.h: Undo Martin's type change.
signal.c: Fix problem identified by Martin with Linux and g++ due to
non-standard declaration of setitimer().
systime.h: Update the docs for "qxe_" to point out why making the
encapsulation explicit is always the right way to go. (setitimer()
itself serves as an example.)
For 21.4:
update-elc-2.el: Correct misplaced parentheses, making lisp/mule not get
recompiled.
author | ben |
---|---|
date | Mon, 18 Jun 2001 07:10:32 +0000 |
parents | e7ef97881643 |
children | 6728e641994e |
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 from start. For 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. 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. 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. These can be specified by the 'package-path' parameter to the 'configure' script. However by default there are three system wide hierarchies. ("$prefix" defaults to "/usr/local") $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. * 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").