From: sperber@toulon.informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Newsgroups: comp.os.linux.announce
Subject: Linux binaries for Lucid Emacs 19.9 available
Date: 29 Jan 1994 23:49:01 +0200
Approved: linux-announce@tc.cornell.edu (Lars Wirzenius)
Message-ID: <2ielkd$hs8@klaava.Helsinki.FI>

Linux binaries for Lucid Emacs 19.9 are now available on the sites
mirroring the standard Lucid Emacs distribution.

Lucid Emacs is a derivative of Emacs 19 for X Windows with multiple X
screens, menus, multi-font handling, scrollbars, XPM support, and many
other goodies.  It comes with a very extensive and well-organized Lisp
library of Emacs utilities.  At the programming level, its substrate
for handling faces, events etc. is much cleaner than that of vanilla
Emacs 19.

The Linux binary distribution includes both dynamically and statically
linked versions.  Both probably require Linux 0.99pl14, and XFree 2.0.
The dynamic version is linked against libc 4.5.8, ld.so 1.3, and XPM
3.3.  Note that the sources compile out of the box against the above
libraries.

Attached to this posting is the original announcement from the Lucid
Emacs distribution which includes a list of sites from which Lucid
Emacs is available.

Enjoy =8-} Chipsy

----
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-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, #<face ... >".
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.

--
Mail submissions for comp.os.linux.announce to: linux-announce@tc.cornell.edu
PLEASE remember Keywords: and a short description of the software.
