Lucid GNU Emacs 19.9 is now available. This is a version of GNU Emacs derived from an early version of Emacs version 19 from the Free Software Foundation. (If you are already a user of version 19.8, you might want to skip ahead to the section labeled "Differences Between 19.8 and 19.9".) You can get it via anonymous FTP from LUCID.COM (192.43.175.3). Note that the IP address of LUCID.COM changed in mid-July, 1993; if you cannot connect, check to see that you are picking up the correct address. Log in with the user "anonymous" and "username@host" as a password (that is, your email address.) Execute the command "cd /pub/lemacs/". These are the files you will find there: README This file. lemacs-19.9.tar.gz The complete source distribution. This file is about 8 megabytes. When unpacked, the source distribution will take up about 30 megs. You will need an additional 12 megs or so to compile it. README.executables Installation instructions for the precompiled binaries. It's important that you read this before unpacking the executables. lemacs-19.9-sun4.tar.gz This contains a set of ready-to-run executables for SunOS 4.1. NOTE: you need to get lemacs-19.9.tar.gz as well for these to work. lemacs-19.9-sol2.tar.gz This contains a set of ready-to-run executables for SunOS 5.2. NOTE: you need to get lemacs-19.9.tar.gz as well for these to work. lemacs-19.9-sun4-energize.tar.gz This contains a set of ready-to-run executables for SunOS 4.1, plus support for Lucid's Energize development environment. If you do not own Energize, then these binaries do not add any features that you can take advantage of. You should probably use the other set of sun4 binaries instead, since these are larger. (Energize users should treat the Energize support in 19.9 as a BETA release.) NOTE: you need to get lemacs-19.9.tar.gz as well for these to work. lemacs-19.9-aix32.tar.gz This contains a set of ready-to-run executables for RS6K/AIX 3.2. NOTE: you need to get lemacs-19.9.tar.gz as well for these to work. lemacs-19.9-hpux9.tar.gz This contains a set of ready-to-run executables for HP-UX 9.01. NOTE: you need to get lemacs-19.9.tar.gz as well for these to work. lemacs-19.9-linux.tar.gz This contains a set of ready-to-run executables for Linux 0.99pl14. NOTE: you need to get lemacs-19.9.tar.gz as well for these to work. lemacs-19.9-netbsd.tar.gz This contains a set of ready-to-run executables for i386 NetBSD 0.9. NOTE: you need to get lemacs-19.9.tar.gz as well for these to work. xpm-3.2g.tar.gz The XPM library (optional.) gzip-1.2.4.tar.Z The GNU compression utility; needed to unpack `.gz' files. You can get the latest version of this from any of the GNU mirror sites. Don't forget to set "binary" mode when transferring these files. Unpack them with some variation of the command "zcat lemacs-19.9.tar.gz | tar -pvxf -". You can also purchase Lucid Emacs tapes and manuals directly from Lucid. Call (800) 223-9322 or send mail to lucid-info@lucid.com for current pricing, media, and platform information. We have created two mailing lists for discussing our Emacs. bug-lucid-emacs@lucid.com For reporting all bugs in Lucid GNU Emacs, including bugs in the compilation and installation procedures. help-lucid-emacs@lucid.com For random questions and conversation about using Lucid GNU Emacs. To be added or removed from these mailing lists, send mail to bug-lucid-emacs-request@lucid.com or help-lucid-emacs-request@lucid.com. The bug-lucid-emacs and help-lucid-emacs mailing lists are archived in the directory /pub/mlists/, and are bidirectionally gatewayed into the newsgroups alt.lucid-emacs.bug and alt.lucid-emacs.help. Please do not send messages about problems with Lucid GNU Emacs to the FSF GNU Emacs newsgroups and mailing lists (help-gnu-emacs@prep.ai.mit.edu, bug-gnu-emacs@prep.ai.mit.edu, gnu.emacs.help, gnu.emacs.bug, et cetera) unless you are sure that the problem you are reporting is a problem with both versions of GNU Emacs. People who aren't subscribed to the Lucid GNU Emacs mailing lists most likely are not interested in hearing about problems with it. Why Another Version of Emacs? ============================= Lucid's latest product, Energize, is a C/C++ development environment. Rather than invent (and force our users to learn) a new user-interface, we chose to build part of our environment on top of the world's best editor, GNU Emacs. (Though our product is commercial, the work we did on GNU Emacs is free software, and is useful without having to purchase our product.) We needed a version of Emacs with mouse-sensitive regions, multiple fonts, the ability to mark sections of a buffer as read-only, the ability to detect which parts of a buffer has been modified, and many other features. Why Not Epoch or FSF19? ======================= For our purposes, the existing version of Epoch was not sufficient; it did not allow us to put arbitrary pixmaps/icons in buffers, `undo' did not restore changes to regions, regions did not overlap and merge their attributes in the way we needed, and several other things. We could have devoted our time to making Epoch do what we needed (and, in fact, we spent some time doing that in 1990) but, since the FSF planned to include Epoch-like features in their version 19, we decided that our efforts would be better spent improving Emacs 19 instead of Epoch. Our original hope was that our changes to Emacs would be incorporated into the "official" v19. However, scheduling conflicts arose, and we found that, given the amount of work still remaining to be done, we didn't have the time or manpower to do the level of coordination that would be necessary to get our changes accepted by the FSF. Consequently, we released our work as a forked branch of Emacs, instead of delaying any longer. Roughly a year after Lucid Emacs 19.0 was released, a beta version of the FSF branch of Emacs 19 was released. The FSF version is better in some areas, and worse in others, as reflects the differing focus of our development efforts. We plan to continue developing and supporting Lucid Emacs, and merging in bug fixes and new features from the FSF branch as appropriate; we do not plan to discard any of the functionality that we implemented which RMS has chosen not to include in his version. Certain elements of Lucid Emacs, or derivatives of them, have been ported to the FSF version. We have not been doing work in this direction, because we feel that Lucid Emacs has a cleaner and more extensible substrate, and that any kind of merger between the two branches would be far easier by merging the FSF changes into our version than the other way around. We have been working closely with the Epoch developers to merge in the remaining Epoch functionality which Lucid Emacs does not yet have. Epoch and Lucid Emacs will soon be one and the same thing. Work is being done on a compatibility package which will allow Epoch 4 code to run in Lemacs with little or no change. (As of 19.8, Lucid Emacs is running a descendant of the Epoch redisplay engine.) No Warranty =========== Lucid Emacs is distributed under exactly the same terms as GNU Emacs, and thus has no warranty of any kind. However, if you have received this version of Emacs with Energize, then it is covered by your Energize support contract. If you have received it through some other means, then you may buy a support contract for it from Lucid. Send mail to lucid-info@lucid.com for more information about Lucid Emacs or Energize. What's Different? ================= Lucid Emacs *currently* requires an X Window System environment to run, though it will not be much work to make it run on dumb ttys again. We plan to do this eventually. If you would like to volunteer to help, send us mail. Because of our functionality requirements and manpower constraints, we have not been able to spend as much time on portability issues as we would like; consequently, Lucid Emacs is not necessarily as easy to bring up on other systems as the other branches of Emacs are. We are very eager to get feedback about portability problems from those who compile it on other systems. We have reimplemented the basic input model in a more general way; instead of X input being a special-case of the normal ASCII input stream, Emacs has a concept of "input events", and ASCII characters are a subset of that. The events that Emacs knows about are not X events, but are a generalization of them, so that Emacs can eventually be ported to different window systems. We have reimplemented keymaps so that sequences of events can be stored into them instead of just ASCII codes; it is possible to, for example, bind different commands to each of the chords Control-h, Control-H, Backspace, Control-Backspace, and Super-Shift-Backspace. Key bindings, function key bindings, and mouse bindings live in the same keymaps. Input and display of all ISO-8859-1 characters is supported. You can have multiple X windows ("screens" in lemacs terminology). Our Emacs has objects called "extents" and "faces", which are roughly analogous to Epoch's "buttons," "zones," and "styles." An extent is a region of text (a start position and an end position) and a face is a collection of textual attributes like fonts and colors. Every extent is displayed in some "face", so changing the properties of a face immediately updates the display of all associated extents. Faces can be screen-local: you can have a region of text which displays with completely different attributes when its buffer is viewed from a different X window. The display attributes of faces may be specified either in lisp or through the X resource manager. Variable width fonts work. The height of a line is the height of the tallest font on that line, instead of all lines having the same height. Emacs use the MIT "Xt" toolkit instead of raw Xlib calls, which makes it be a more well-behaved X citizen (and also improves portability). A result of this is that it is possible to include other Xt "Widgets" in the Emacs window. Also, Emacs understands the standard Xt command-line arguments. Emacs understands the X11 "Selection" mechanism; it's possible to define and customize selection converter functions and new selection types from elisp, without having to recompile Emacs. Emacs now supports the Zmacs/Lispm style of region highlighting, where the region between the point and mark is highlighted when in its "active" state. Emacs has a menubar, whose contents are customizable from emacs-lisp. This menubar looks Motif-ish, but does not require Motif. If you already own Motif, however, you can configure Emacs to use a *real* Motif menubar instead. If you have OLIT ("OpenLook Intrinsics"), you can use an OpenWindows-like menubar. Emacs can ask questions using popup dialog boxes. Any command executed from a menu will ask yes/no questions with dialog boxes, while commands executed via the keyboard will use the minibuffer. The initial load-path is computed at run-time, instead of at compile-time. This means that if you move the Emacs executable and associated directories to somewhere else, you don't have to recompile anything. You can specify what the title of the Emacs windows and icons should be with the variables `screen-title-format' and `screen-icon-title-format', which have the same syntax as `mode-line-format'. Emacs now supports floating-point numbers. Emacs now knows about timers directly, instead of them being simulated by a subprocess. Emacs understands truenames, and can be configured to notice when you are visiting two names of the same file. If you're running on a machine with audio hardware, you can specify sound files for Emacs to play instead of the default X beep. Much more detail about the differences between Lucid Emacs and Emacs 18 can be found in the file .../etc/NEWS (accessible with ``C-h n''.) Note that building Lucid Emacs requires an ANSI C compiler, like gcc, or Lucid's own (and the galaxy's best) Lucid C/C++. Differences between Lucid Emacs 19 and FSF Emacs 19 =================================================== In Lucid Emacs, events are first-class objects. FSF19 represents them as integers, which obscures the differences between a key gesture and the ancient ASCII code used to represent a particular overlapping subset of them. In Lucid Emacs, keymaps are first-class opaque objects. FSF19 represents them as complicated combinations of association lists and vectors. If you use the advertised functional interface to manipulation of keymaps, the same code will work in Lucid Emacs, Emacs 18, and and FSF Emacs 19; if your code depends on the underlying implementation of keymaps, it will not. Lucid Emacs calls a top-level emacs X window a "screen," which is the terminology that Epoch used. FSF 19 calls these "frames." We may adopt the term "frame" as well, but we have not done so yet. Lucid Emacs uses "extents" to represent all non-textual aspects of buffers; FSF 19 uses two distinct objects, "text properties" and "overlays", which divide up the functionality between them. Extents are a superset of the functionality of the two FSF data types. A large subset of the FSF 19 interface to text properties is supported in lemacs (with extents being the underlying representation.) Extents can be made to be copied into strings, and thus restored by kill and yank. Thus, one can specify this behavior on either "extents" or "text properties", whereas in FSF 19 text properties always have this behavior and overlays never do. Major Differences Between 19.8 and 19.9 ======================================= Scrollbars! If you have Motif, these are real Motif scrollbars; otherwise, Athena scrollbars are used. They obey all the usual resources of their respective toolkits. There is now an implementation of dialog boxes based based on the Athena widgets, as well as the existing Motif implementation. This release works with Motif 1.2 as well as 1.1. If you link with Motif, you do not also need to link with Athena. If you compile lwlib with both USE_MOTIF and USE_LUCID defined (which is the recommended configuration) then the Lucid menus will draw text using the Motif string-drawing library, instead of the Xlib one. The reason for this is that one can take advantage of the XmString facilities for including non-Latin1 characters in resource specifications. However, this is a user-visible change in that, in this configuration, the menubar will use the "*fontList" resource in preference to the "*font" resource, if it is set. It's possible to make extents which are copied/pasted by kill and undo. There is an implementation of FSF19-style text properties based on this. There is a new variable, minibuffer-max-depth, which is intended to circumvent a common source of confusion among new Emacs users. Since, under a window system, it's easy to jump out of the minibuffer (by doing M-x, then getting distracted, and clicking elsewhere) many, many novice users have had the problem of having multiple minibuffers build up, even to the point of exhausting the lisp stack. So the default behavior is to disallow the minibuffer to ever be reinvoked while active; if you attempt to do so, you will be prompted about it. There is a new variable, teach-extended-commands-p, which if set, will cause `M-x' to remind you of any keybindings of the command you just invoked the "long way." There are menus in Dired, Tar, Comint, Compile, and Grep modes. There is a menu of window management commands on the right mouse button over the modelines. Popup menus now have titles at the top; this is controlled by the new variable `popup-menu-titles'. The `Find' key on Sun keyboards will search for the next (or previous) occurrence of the selected text, as in OpenWindows programs. The `timer' package has been renamed to `itimer' to avoid a conflict with a different package called `timer'. VM 5.40 is included. W3, the emacs interface to the World Wide Web, is included. Felix Lee's GNUS speedups have been installed, including his new version of nntp.el which makes GNUS efficiently utilize the NNTP XOVER command if available (which is much faster.) GNUS should also be much friendlier to new users: it starts up much faster, and doesn't (necessarily) subscribe you to every single newsgroup. The byte-compiler issues a new class of warnings: variables which are bound but not used. This is merely an advisory, and does not mean the code is incorrect; you can disable these warnings in the usual way with the `byte-compiler-options' macro. the `start-open' and `end-open' extent properties, for specifying whether characters inserted exactly at a boundary of an extent should go into the extent or out of it, now work correctly. The `extent-data' slot has been generalized/replaced with a property list, so it's easier to attach arbitrary data to extent objects. The `event-modifiers' and `event-modifier-bits' functions work on motion events as well as other mouse and keyboard events. Forms-mode uses fonts and read-only regions. The behavior of the -geometry command line option should be correct now. The `iconic' screen parameter works when passed to x-create-screen. The user's manual now documents Lucid Emacs 19.9. The relocating buffer allocator is turned on by default; this means that when buffers are killed, their storage will be returned to the operating system, and the size of the emacs process will shrink. CAVEAT: code which contains calls to certain `face' accessor functions will need to be recompiled by version 19.9 before it will work. The functions whose callers must be recompiled are: face-font, face-foreground, face-background, face-background-pixmap, and face-underline-p. The symptom of this problem is the error "Wrong type argument, arrayp, #". The .elc files generated by version 19.9 will work in 19.6 and 19.8, but older .elc files which contain calls to these functions will not work in 19.9. Interactively changing the width of the scrollbars or toggling the visibility of the menubars may lead to odd behavior with some window managers. Resizing the top-level window repairs things. This will be fixed in the next release. Work In Progress: - We have been in the process of internationalizing Lucid Emacs. This code is ***not*** ready for general use yet. However, the code is included (and turned off by default) in this release. - If you define I18N2 at compile-time, then sorting/collation will be done according to the locale returned by setlocale(). - If you define I18N3 at compile-time, then all messages printed by lemacs will be filtered through the gettext() library routine, to enable the use of locale-specific translation catalogues. The current implementation of this is quite dependent on Solaris 2, and has a very large impact on existing code, therefore we are going to be making major changes soon. (You'll notice calls to `gettext' and `GETTEXT' scattered around much of the lisp and C code; ignore it, this will be going away.) - If you define I18N4 at compile-time, then lemacs will internally use a wide representation of characters, enabling the use of large character sets such as Kanji. This code is very OS dependent: it requires X11R5, and several OS-supplied library routines for reading and writing wide characters (getwc(), putwc(), and a few others.) Performance is also a problem. This code is also scheduled for a major overhaul, with the intent of improving performance and portability. Our eventual goal is to merge with MULE, or at least provide the same base level of functionality. If you would like to help out with this, let us know. - Other work-in-progress includes Motif drag-and-drop support, ToolTalk support, and support for embedding an Emacs widget inside another application (where it can function as that other application's text-entry area). This code has not been extensively tested, and may (or may not) have portability problems, but it's there for the adventurous. Comments, suggestions, bug reports, and especially fixes are welcome. But have no expectations that this experimental code will work at all.