Mercurial > hg > xemacs-beta
view README @ 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 | eba92770173a |
| children | 715eed24e30e |
line wrap: on
line source
This directory tree holds version 21.5 of XEmacs. *** What is XEmacs? XEmacs is a powerful, highly customizable open source text editor and application development system, with full GUI support. It is protected under the GNU Public License and related to other versions of Emacs, in particular GNU Emacs. Its emphasis is on modern graphical user interface support and an open software development model, similar to Linux. XEmacs has an active development community numbering in the hundreds (and thousands of active beta testers on top of this), and runs on all versions of MS Windows, on Linux, and on nearly every other version of Unix in existence. Support for XEmacs has been supplied by Sun Microsystems, University of Illinois, Lucid, ETL/Electrotechnical Laboratory, Amdahl Corporation, BeOpen, and others, as well as the unpaid time of a great number of individual developers. *** What platforms does it run on? -- MS Windows (It has been tested on NT, 2000, 95, 98, and ME; you can also compile Cygwin and MinGW versions.) -- Unix (It is regularly tested on Linux, Solaris, SunOS, HP/UX, FreeBSD, OpenBSD, BSD/OS aka BSDI, Tru64 aka DEC/OSF, SCO5, and probably others. It should work on all versions of Unix created in the last 10 years or so, perhaps with a bit of work on more obscure platforms to correct bit-rot. It uses a sophisticated configuration system to auto-detect zillions of features that are implemented differently in different versions of Unix, so it will probably work on your vendor's version, possibly with a bit of tweaking, even if we've never heard of it.) -- MacOS/X (As an X Windows application. Unfortunately there is no support currently for MacOS-specific features.) There is also a port of XEmacs 19.14 (an older version, circa 1996) for all versions of MacOS, with extensive support for MacOS-specific features. See the FAQ for more details. There are rumors of an in-progress port to OS/2. See the FAQ. XEmacs will probably never work on MS/DOS or Windows 3.1, and we're not particularly interested in patches for these platforms, as they would introduce huge amounts of code clutter due to the woefully underfeatured nature of these systems. (See GNU Emacs for a port to MS/DOS.) *** Where's the FAQ? Look at `man/xemacs-faq.texi'. For the very latest version, see http://cvs.xemacs.org/cgi-bin/cvswebxe/xemacs/man/xemacs-faq.texi. *** Where's the latest version? For up-to-date information on XEmacs, see http://www.xemacs.org. To download XEmacs, see http://ftp.xemacs.org/ or ftp://ftp.xemacs.org/pub/xemacs/. For the latest experimental sources, see http://cvs.xemacs.org/, which gives instructions on how to get started with CVS access. There are numerous mailing lists for discussion of XEmacs. The current description of these lists can be found at http://www.xemacs.org/Lists/, or see `etc/MAILINGLISTS'. General discussion of bugs, new features, etc. takes place on xemacs-beta@xemacs.org. *** How do I build and install XEmacs? See the file `etc/NEWS' for information on new features and other user-visible changes since the last version of XEmacs. The file `INSTALL' in this directory says how to bring up XEmacs on Unix and Cygwin, once you have loaded the entire subtree of this directory. See the file `nt/README' for instructions on building XEmacs for Microsoft Windows. The file 'README.packages' will guide you in the installation of (essential) add on packages. *** How do I deal with bugs or with problems building, installing, or running? The file `PROBLEMS' contains information on many common problems that occur in building, installing and running XEmacs. Reports of bugs in XEmacs should be sent to xemacs-beta@xemacs.org. You can also post to the newsgroup comp.emacs.xemacs (or equivalentlt, send to the mailing list xemacs@xemacs.org), but it is less likely that the developers will see it in a timely fashion. See the "Bugs" section of the XEmacs manual for more information on how to report bugs. (The file `BUGS' in this directory explains how you can find and read that section using the Info files that come with XEmacs.) See `etc/MAILINGLISTS' for more information on mailing lists relating to XEmacs. *** How do I get started developing XEmacs? First, get yourself set up under CVS so that you can access the CVS repositories containing the XEmacs sources and the XEmacs packages. Next, set up your layout. This is important, as a good layout will facilitate getting things done efficiently, while a bad layout will could lead to disaster, as you can't figure out which code is the most recent, which can be thrown away, etc. We suggest the following layout: (feel free to make changes) -- Everything goes under /src/xemacs (use a different directory if you want). From now, instead of saying /src/xemacs, we use <xsrc-top>, to make it easier in case someone picked a different directory. -- Package source is in <xsrc-top>/package-src. -- Installed packages go under <xsrc-top>/xemacs-packages, and <xsrc-top>/mule-packages. -- A "workspace" is a complete copy of the sources, in which you do work of a particular kind. Workspaces can be differentiated by which branch of the source tree they extend off of -- usually either the stable or experimental, unless other branches have been created (for example, Ben created a branch for his Mule work because (1) the project was long-term and involved an enormous number of changes, (2) people wanted to be able to look at what his work in progress, and (3) he wanted to be able to check things in and in general use source-code control, since it was a long-term project). Workspaces are also differentiated in what their purpose is -- general working workspace, workspace for particular projects, workspace keeping the latest copy of the code in one of the branches without mods, etc. -- Various workspaces are subdirectories under <xsrc-top>, e.g.: -- <xsrc-top>/working (the workspace you're actively working on, periodically synched up with the latest trunk) -- <xsrc-top>/stable (for making changes to the stable version of XEmacs, which sits on a branch) -- <xsrc-top>/unsigned-removal (a workspace for a specific, difficult task that's going to affect lots of source and take a long time, and so best done in its own workspace without the interference of other work you're doing. Also, you can commit just this one large change, separate from all the other changes). -- <xsrc-top>/latest (a copy of the latest sources on the trunk, i.e. the experimental version of XEmacs, with no patches in it; either update it periodically, by hand, or set up a cron job to do it automatically). Set it up so it can be built, and build it so you have a working XEmacs. (Building it might also go into the cron job.) This workspace serves a number of purposes: -- 1. You always have a recent version of XEmacs you can compare against when something you're working on breaks. It's true that you can do this with cvs diff, but when you need to do some serious investigation, this method just fails. -- 2. You (almost) always have a working, up-to-date executable that can be used when your executable is crashing and you need to keep developing it, or when you need an `xemacs' to build packages, etc. -- 3. When creating new workspaces, you can just copy the `latest' workspace using GNU cp -a. You have all the .elc's built, everything else probably configured, any spare files in place (e.g. some annoying xpm.dll under Windows, etc.). -- <xsrc-top>/latest-stable/ (equivalent to <xsrc-top>/latest/, but for the Stable branch of XEmacs, rather than the Experimental branch of XEmacs). This may or may not be necessary depending on how much development you do of the stable branch. -- <xsrc-top>/xemacsweb is a workspace for working on the XEmacs web site. -- <xsrc-top>/in-patches for patches received from email and saved to files. -- <xsrc-top>/out-patches for locally-generated patches to be sent to xemacs-patches@xemacs.org. Less useful now that the patcher util has been developed. -- <xsrc-top>/build, for build trees when compiling and testing XEmacs with various configuration options turned off and on. The scripts in xemacs-builds/ben (see below) can be used to automate building XEmacs workspaces with many different configuration options and automatically filtering out the normal output so that you see only the abnormal output. -- <xsrc-top>/xemacs-builds, for the xemacs-builds module, which you need to check out separately in CVS. This contains scripts used for building XEmacs, automating and simplifying using CVS, etc. Under various people's directories are their own build and other scripts. The currently most-maintained scripts are under ben/, where there are easily configurable scripts that can be used to easily build any workspace (esp. if you've more or less followed the layout presented above) unattended, with one or more configuration states (there's a pre-determined list of the most useful, but it's easy to change). The output is filtered and split up in various ways so that you can identify which output came from where, and you can see the output either full or with all "normal" output except occasional status messages filtered so that you only see the abnormal ones. *** What's the basic layout of the code? The file `configure' is a shell script to acclimate XEmacs to the oddities of your processor and operating system. It will create a file named `Makefile' (a script for the `make' program), which helps automate the process of building and installing emacs. See INSTALL for more detailed information. The file `configure.in' is the input used by the autoconf program to construct the `configure' script. Since XEmacs has configuration requirements that autoconf can't meet, `configure.in' uses an unholy marriage of custom-baked configuration code and autoconf macros; it may be wise to avoid rebuilding `configure' from `configure.in' when possible. The file `Makefile.in' is a template used by `configure' to create `Makefile'. There are several subdirectories: `src' holds the C code for XEmacs (the XEmacs Lisp interpreter and its primitives, the redisplay code, and some basic editing functions). `lisp' holds the XEmacs Lisp code for XEmacs (most everything else). `lib-src' holds the source code for some utility programs for use by or with XEmacs, like movemail and etags. `etc' holds miscellaneous architecture-independent data files XEmacs uses, like the tutorial text and the Zippy the Pinhead quote database. The contents of the `lisp', `info' and `man' subdirectories are architecture-independent too. `lwlib' holds the C code for the X toolkit objects used by XEmacs. `info' holds the Info documentation tree for XEmacs. `man' holds the source code for the XEmacs online documentation. `nt' holds files used compiling XEmacs under Microsoft Windows.