🚀 go-pugleaf

Lucid GNU Emacs 19.4 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.3, you might want to skip ahead to
the section labeled "Differences Between 19.3 and 19.4".)

You can get it via anonymous FTP from labrea.Stanford.EDU (36.8.0.112).  It
is currently available only by FTP.  We don't have the manpower to make tapes
right now.

Log in with the user "anonymous" and "username@host" as a password (that is,
your email address.)  Execute the command "cd pub/gnu/lucid/".  These are
the files you will find there:

  lemacs-19.4.tar.Z
	The complete source distribution.  This file is about 9 megabytes.
	When untarred and uncompressed, the source distribution will take up
	about 22 megs. You will need an additional 12 megs or so to compile it.

  lemacs-19.4-sun4.tar.Z
	This is a ready-to-run set of Sun4 executables, and a DOC file.  If
	you want to use these executables, you will still need to get the file
	lemacs-19.4.tar.Z, because Emacs cannot function very well without the
	lisp library online.  This file is about 2.5 megs, 4.9 megs when
	unpacked, 3.6 megs of which is the Emacs executable itself (2.5 megs if
	stripped.)  This version of lemacs is compiled with support for Motif
	dialog boxes and XPM files.

  xpm-3.2a.tar.Z
	The XPM library (optional.)

Don't forget to set "binary" mode when transferring these files.  Unpack them
with some variation of the command "zcat lemacs-19.4.tar.Z | tar -vxf -".

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 on labrea,
and are bidirectionally gatewayed into the newsgroups alt.lucid-emacs.bug and
alt.lucid-emacs.help.

The bug-lucid-emacs and help-lucid-emacs mailing lists are archived on labrea.

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?
==============

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) but, since the FSF planned to include
Epoch-like features in their version 19, we decided that our efforts would 
be better spent improving Emacs19 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 time to
merge with the FSF's code.  Consequently, we have released our work as a
forked branch of Emacs, instead of delaying any longer.

Work has begun on a merger of Epoch and Lucid Emacs.  It seems likely that 
the next release of Epoch will be based on Lucid Emacs instead of GNU Emacs
from the FSF.  At some point, Lucid Emacs and Epoch will probably be the 
same thing.

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 X Windows to run, though it will not be much
work to make it run on dumb ttys again.  We plan to do this eventually.

We have not personally tried to compile this version of Emacs under anything
but SunOS 4.1 on SparcStations, though others have successfully done so.  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 Emacs 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.

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.

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 sun SparcStation, 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++.


Major Differences Between 19.3 and 19.4
=======================================

Prototypes have been added for all functions.  Emacs compiles in the strict
ANSI modes of lcc and gcc, so portability should be vastly improved.

Many many many many core leaks have been plugged, especially in screen 
creation and deletion.

The float support reworked to be more portable and ANSI conformant.  This
resulted in these new configuration parameters: HAVE_INVERSE_HYPERBOLIC, 
HAVE_CBRT, HAVE_RINT, FLOAT_CHECK_ERRNO, FLOAT_CATCH_SIGILL, 
FLOAT_CHECK_DOMAIN.  Let us know if you had to change the defaults on your
architecture.

The SunOS unexec has been rewritten, and now works with either static or 
dynamic libraries, depending on whether -Bstatic or -Bdynamic were specified
at link-time.

Small (character-sized) bitmaps can be mixed in with buffer text via the new
functions set-extent-begin-glyph and set-extent-end-glyph.  (This is actually
a piece of functionality that Energize has been using for a while, but we've
just gotten around to making it possible to use it without Energize.  See how
nice we are?  Go buy our product.)

If compiled with Motif support, one can pop up dialog boxes from emacs lisp.
We encourage someone to contribute Athena an version of this code; it
shouldn't be much work.  

If dialog boxes are available, then y-or-n-p and yes-or-no-p use dialog boxes
instead of the minibuffer if invoked as a result of a command that was 
executed from a menu instead of from the keyboard.

Multiple screen support works better; check out doc of get-screen-for-buffer.

The default binding of backspace is the same as delete.  (C-h is still help.)

A middle click while the minibuffer is active does completion if you click on 
a highlighted completion, otherwise it executes the global binding of button2.

New versions of Barry Warsaw's c++-mode and syntax.c.  Font-lock-mode works
with C++ mode now.

The semantics of activate-menubar-hook has changed; the functions are called
with no arguments now.

`truename' no longer hacks the automounter; use directory-abbrev-alist instead.

Most minibuffer handling has been reimplemented in emacs-lisp.