About a merged Emacs
Richard Stallman
willing to do?
If the work of merging is up to the FSF, then I can say how we will do
it. We'll try to make a version that has all the capabilities of both
versions, with as little work as possible. In many cases, we have
both implemented pretty much equivalent functionality; we will stick
with our implementations of these, while merging in capabilities that
we don't have. (These mainly relate to Xt use, and things needed to
support it.)
Once such a merged version exists, what would happen then? Will you
work on that version, together with us?
I hope so. If you keep working on new features in the current Lucid
version, each feature will require considerable rewriting to fit into
the merged version. That way the job of merging would be unending.
Jamie Zawinski
insufficient motivation on the part of FSF to compromise. In particular, we
are concerned that FSF will decide not to include features that we consider
critical, or that those features will have an interface that is quite
different from what we need and are implemented in a way that preclude
supporting the interface that we need.
However, if there was a version of emacs from the FSF that did everything that
we require from Lucid Emacs, then we would use it. Also, if v19 has a better
interface to something than what we designed, we would be motivated to use it.
(In general, a change in the interfaces will make the merge harder, and make
it take longer, but it doesn't preclude our switching. An implementation or
interface that eliminated functionality important to us would preclude a
merge.)
Here are the things (that we can think of at the moment) that we believe we
need in a merged version, in no particular order:
We don't want to lose our tight integration with the Xt event loop, so that
we can link arbitrary widgets into emacs.
We want our implementation of keymaps to be used: we want them to be an
abstract data type, not something like "if the third element of the alist is
a cons whose car is a vector of length 7, then it represents an aliased
indirection into the sixth element of the alist..." (NOTE: Having support
for "secondary" data types, similar to structure subtypes in Common Lisp,
would be quite acceptable, but alists are not.)
We don't want any ASCII limitations: all X chords should be bindable.
We want our extensions to the syntax for the define-key function to work.
We want input and display of all ISO-8859-1 characters.
We want ICCCM compliance.
We want a menubar, popup menus, and dialog boxes, and the ability to use the
native toolkit widgets to implement it to guarantee that they comply with
local look-n-feel customs.
We want the menubar to be buffer-local, and update efficiently.
We want the menubar to display the keybindings corresponding to the commands
listed in it, and update this dynamically.
We want to avoid compiling pathnames into the emacs executable: it should
figure out where things are at run-time based on the location of the
executable.
We do not want menus implemented in terms of keymaps or anything odd like
that. This sort of false generality just makes things harder to maintain.
We want our implementation of extents and faces, or something with a
superset of the functionality and performance characteristics.
We want zmacs-style region highlighting.
Richard Stallman
the FSF does all the work of producing it.
But this sounds like a statement that Lucid is not willing to do any
of the work necessary to produce a merged version. I'm sad to hear
that. At the same time, Lucid sounds very exigent regarding what
features we should include and exclude.
Thus, we have a combination of stringent demands, with a refusal to
help accomplish them. The combination sets up a situation where
cooperation is predictably unlikely. We will certainly merge in the
features that seem important (those we don't have already), but
whether we merge in every last thing Lucid wants, depends on our
resources and on how generally useful the features seem to us.
We can install more of the features Lucid wants if Lucid helps do the
job.
A couple of specific points are disturbing in another way: they seem
to insist that we remove some of the features of GNU Emacs 19--such
as, its unification of menus with keymaps, and its use of standard
Lisp data types rather than creating new opaque types.
Is there any chance you could accept a compromise? Such as support
for the interfaces that you now use, as well as the ones we prefer?
Jamie Zawinski
> But this sounds like a statement that Lucid is not willing to do any
> of the work necessary to produce a merged version.
This is not the case; we are willing to help work towards a merge.
We are not willing to do it ourselves unless you say that we get to
be the final arbiter of what goes in. Without that, we do not, at
this time, have any confidence that we won't be wasting our time.
The facts speak for themselves: we have tried very hard to work with
the FSF. We have spent hundreds of thousands of dollars and several
man-years on it. Clearly we have not done so successfully, regardless
of where the fault for the failure lies, but we did try, that is
undeniable.
We don't think it's too much to ask for you to make the first move as
a show of faith. We've been burned before. We'd like to see some
commitment from your side before committing any more money or resources
to this endeavor.
> At the same time, Lucid sounds very exigent regarding what features
> we should include and exclude.
Whether you include or exclude them from your version of emacs is your
decision. But these are features we need, and if they are not in your
version of emacs, then your version of emacs will simply not be adequate
for our purposes.
> A couple of specific points are disturbing in another way: they seem
> to insist that we remove some of the features of GNU Emacs 19--such
> as, its unification of menus with keymaps, and its use of standard
> Lisp data types rather than creating new opaque types.
You call them features, we call them bugs. We have contractual obligations
to maintain the version of emacs that we distribute, and the design of the
data structures used has a great bearing on how difficult that is.
> Is there any chance you could accept a compromise? Such as support
> for the interfaces that you now use, as well as the ones we prefer?
Yes, compromise is always possible.
-- Jamie
Richard Stallman
identical. In the past, Lucid has done a lot of work on Lucid Emacs,
but only rarely tried to work with the FSF.
Your latest message states the intention to do some work on merging in
the future, which is good. The emotional tone, shows a contrary
attitude. I'm not sure what to make of this mixed message.
The FSF will merge in some features of Lucid Emacs in any case, now
that I see they are reasonable to use. Specifically, those that
pertain to generic interfaces to window-system support code, followed
by the support for an X toolkit as a compile-time option.
In principle, there's no capability that we would object to supporting
in some fashion. Some we would do the work to add, but some we would
not (if we think it is of minor importance or that we have a better
capability already). Thus, merging of the latter class depends on
what Lucid does.
Richard Stallman
is clean, simple and convenient to have keymaps serve also as menus.
You think an abstract interface is cleaner.
If we are limited to choosing between one of two alternatives, this
looks like an irreconcilable difference.
I've proposed one compromise--supporting your interface and ours--but
you don't like that.
Can you please propose another?
Kevin Gallagher
> We want input and display of all ISO-8859-1 characters.
All editors today should strive for this.
> We want to avoid compiling pathnames into the emacs executable: it should
> figure out where things are at run-time based on the location of the
> executable.
The ability to port executables from one node to another node of the same type
in the network, WITHOUT rebuilding the executable, is extremely important in
today's distributed computing environment.
> We want zmacs-style region highlighting.
This is very important to a large percentage of emacs users. To think
otherwise is a mistake.
--
----------------------------------------------------------------------------
Kevin Gallagher kgal...@digi.lonestar.org OR ...!uunet!digi!kgallagh
DSC Communications Corporation Addr: MS 152, 1000 Coit Rd, Plano, TX 75075
----------------------------------------------------------------------------
Per Abrahamsen
>>>>> On 4 Mar 1993 15:08:50 -0500, j...@lucid.com (Jamie Zawinski) said:
Jamie> You call them features, we call them bugs.
And everybody else call them implementation details.
Jamie> We have contractual obligations to maintain the version of
Jamie> emacs that we distribute, and the design of the data structures
Jamie> used has a great bearing on how difficult that is.
Instead every system administrator has to maintain two versions of
emacs, and every emacs lisp developer has to maintain two variants of
their code. I will think happily of how easy Lucid Emacs is to
maintain, each time I insert an (if 'running-under-lucid ...)
expression in AUC TeX.