kaplan@kaplan.cs.uiuc.edu (Simon Kaplan) (07/08/90)
Epoch 3.2 Beta is now available. This is as "robust" as previous epoch releases, but given the large number of epoch users out there now, we felt that beta-testing for a while is a useful thing to do. (if you dont know what epoch is and would like to find out, see below) The distribution is available from cs.uiuc.edu (internet address 128.174.252.1) by anonymous ftp (login: anonymous, password: anything). in the pub/epoch-files/epoch directory. The relevent files are: epoch-3.2b.tar.Z EPOCH 3.2 distribution epoch-3.2b.ps.Z postscript version of the manual. There is no epoch-3.1-to-3.2 diff file yet... this will appear in a couple of days. We will send mail to the epoch list when this happens. There is an epoch mailing list for reports of bugs, discussions, etc. To send mail to the list, use epoch@cs.uiuc.edu uunet!uiucdcs!epoch epoch%cs.uiuc.edu@uiucvmd.bitnet to join the list, or be removed from it, or any other administrivia, send mail to epoch-request rather than epoch at any of the addresses above. Epoch 3.2 proper will be available for tape shipment (yes, we promised this for 3.1 and never did make any, but for 3.2 we are now set up to make tapes). A charge for tapes is levied to cover production and distribution costs. This charge is $175.00 US currency only payable by cheque only (sorry). Make your cheques payable to "University of Illinois" and mail to: Epoch Distribution Attn: R. Canaday Department of Computer Science University of Illinois at Urbana-Champaign 1304 W. Springfield Avenue Urbana, IL 61801 USA What is epoch: epoch is an enhanced version of gnu emacs 18.55. changes include: increased compatibility with X windows (multiple screens, fonts, colors, ICCCM compatibility, access to property and client messages) features for hypertext-like tools (buttons, attributed regions of text) various bug fixes. Epoch will work on any machine that runs Gnu Emacs and has at least X11R3. It ONLY RUNS UNDER X WINDOWS. FOR NON X-WINDOW APPLICATIONS YOU MUST USE GNU EMACS INSTEAD. AND NOW, the README file from the distribution... README for Epoch version 3.2 (beta) Major changes: + Epoch now relies on some of the standard lisp files being different from the standard distribution. These are @ version.el : Changed to have "Epoch" in messages @ startup.el : If running Epoch, forces screens 0,1 to be mapped (unless inhibit-initial-screen-mapping is non-nil) @ time.el : display-time-filter now supports hooks in variable display-time-hook. @ loadup.el : Dumps under the name "epoch" instead of "emacs" @ loaddefs.el : Changed to have "Epoch" in the mode line @ backquote.el : Fixed bug with '(@, )'. Only version.el, loaddefs.el, and loadup.el are incompatible with GNU-Emacs 18.55, and these only in that certain messages/displays will say "Epoch" instead of "Emacs". + epoch::create-screen no longer maps screens upon creation. This is a critical difference. This is necessary so that property manipulations can be performed on the screen before it is mapped. The changes in startup.el are primarily to make sure that the first edit screen is mapped if for some reason the init file gets an error. Notice also that for some of the advertised features to work, you must use create-screen, so that the correct properties are set (or take care of them yourself). + Event handling is completely different. Read the manual, look at the code. + Mouse handling is completely different. You can still use the standard Emacs code if you want, but the new version is really a _lot_ better. Read the manual. + Buttons are completely different. Read the manual. There is code in fix3-2.el in the distribution to change (most of the) vector button code to the new format. The new style is based on Denys Duchier's version. Also, read-only buttons are supported now. + The Epoch manual is now in Info format. + X Properties work better (more general). In particular, X resources can be used, and also properties can be set to lists/arrays of values (c.f. WM_PROTOCOLS). Minor changes: - A lot of bug fixes. Should be more stable. See the ChangeLogs for more detail. - Client messages work better. - New handlers for map, resize, and move events. - Multiple packages in different files, loaded by dot.emacs file. - Complete set of wrappers for epoch:: functions. - Standard files now load support for WM_DELETE_WINDOW client message from WM. (This means that a "quit" selection from window managers that obey the ICCCM delete-window protocol will cause that window to be deleted, rather than blowing away all of Epoch. A window manager that does this is Suns OLWM.) - Epoch 3.1 would "spin" if the X server died while epoch was running or if you killed epoch from a window-manager window. We have reduced this problem under 3.2. Now, if you delete epoch windows (or an entire epoch) from a window-manager, or if you terminate the X server normally, epoch will die. The only time this fix does not work is if the X server itself terminates abnormally (ie it core dumps). Since this is a very abnormal condition we dont know how to deal with it. - Under SunOs4.0.3, epoch 3.1 would sometimes coredump due to a bug in TZSETWALL causing Gnu Malloc to crash. This is protected against in epoch 3.2. - Alan's Epoch environment files are in the ./amc-lisp directory. These should be considered example, not official code. UPGRADING: Several things are involved in upgrading code from 3.1 to 3.2. + Use of epoch:: functions - there should be wrappers for almost all of the epoch::functions, except a few special cases (noted in the manual). This is particularly important for create-screen, which has a lot of functionality beyond epoch::create-screen. + Use the "dot.emacs" included in ./epoch-lisp. If possible, simply load that file in your own .emacs. If not, you must update your .emacs to reflect the new files/ordering in the dot.emacs file. + Buttons are data types, so the old vector munging code won't work. Such references will have to be changed to use the button access functions. See the code in fix3-2.el. + Mouse handling is different. Epoch now supports "mouse-maps" which work a lot like key maps. Instead of munging the mouse dispatch stuff, you can just do (global-set-mouse mouse-left mouse-control 'my-mouse-function) to set control-left-button to execute 'my-mouse-function. Buffer local mouse maps can be installed with (use-local-mouse-map) and (local-set-mouse). Mouse functions are not called with coordinates, but with a list of (POINT BUFFER WINDOW SCREEN), which we think is a lot more convienient. When the function is called, the point (and current buffer/window/screen) has _NOT_ been changed from what they were before the mouse click. If you want them changed, you should do it yourself. On the other hand, if you don't want it changed, you're all set. + Property handling is different. To dispatch on a property change, use the (push-property) function to set up a handler. KNOWN BUGS: The standard Elisp files are in Alan's bizarro indentation style. To convert them to a readable format, use the code in uglify.el, which will convert a buffer to a (mostly) standard format. On the other hand, if you like that style, support for it is in ./amc-lisp/amc-lisp.el. There are two reported bugs which we have not been able to track down yet. It is reported that if Epoch is used as a server for extended periods, it will eventually crash. We have not observered this ourselves, but it has been reported by multiple other users, apparently mostly (or all) on Ultrix systems. Sometimes when switch files in the minibuffer and a garbage collect happens, Epoch will core dump. If either of these happen to you please report it, along with as much detail as you can, including the Epoch version, your OS version, X version, and hardware. Epoch, when made on certain machines using gcc 1-37 and gcc-gnulib, runs extremely slowly. This problem is known to manifest itself on Sun3, Sun386i and Encore Multimax (all bsd unices of various kinds) but NOT on intel 386i running 386/IX sysV Unix. It isnt clear if it happens on Sparc machines 'cuz they are so fast (but we *think* epoch is a little slower with gcc). So, if you make the system with GCC and it is SLOOOWW, then try the generic cc on your machine instead. If you can fix this problem please! let us know about it. Since epoch runs slowly with gcc compile and not with cc compile, we dont think it is an epoch problem.