carroll@cs.uiuc.edu (Alan M. Carroll) (10/28/90)
Version 3.2 of Epoch, GNU Emacs for the X windowing system has been formally released. It is available by anonymous ftp from cs.uiuc.edu (128.174.252.1) in the directory pub/epoch-files/epoch either as a full distribution or as patches from either the Epoch 3.1 or Epoch 3.2 Beta distributions. There is also an epoch mailing list. To join the list or get more information about obtaining epoch, email epoch-request@cs.uiuc.edu, uunet!uiucdcs!epoch-request or (as a last resort) epoch-request%cs.uiuc.edu@uiucvmd.bitnet. Epoch is a modified version of GNU Emacs 18.55 with several major enhancements: o Multiple X-Window support o Marked and Attributed regions of text o Support for multiple fonts (fixed size), underlining, and stipple patterns. o Asynchronous communication with other X-Clients (usually the window manager) o Mouse-dragging with highlighting to support mouse-based cut-and- paste. o Access to raw X-Window objects README for Epoch version 3.2 Major changes: + Epoch elisp code is now dumped when Epoch is built. See loadup.el in lisp directory for which files are dumped. dot.emacs should load any elisp files which are not dumped. (Or if memory prohibits dumping files) + 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. + Handling of attributes is completely different. The complete context for displaying text (i.e. foreground/background color, stipple pattern, font, underline color, etc.) is now specified in a "style" structure. Attribute tables are now references to styles. Read the manual for further details. + 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. u + 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 contrib/amc directory. These should be considered example, not official code. Other contributed code is located in the contrib directory also. It has been verified to run with Epoch 3.2, but is not considered official code. INSTALLING: The file `INSTALL' in this directory says how to bring up Epoch on Unix, once you have loaded the entire subtree of this directory. The files `build-install' and `Makefile' help automate the process of building and installing epoch. The former is a shell script. See `INSTALL' for more info. UPGRADING TO EPOCH 3.2: 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 contrib/amc/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.