FSF emacs - lemacs merge? (was Re: beta testers sought)
Richard Mlynarik
Date: Mon, 3 May 1993 15:35:50 -0700
>Does this in any way imply that a merge of the two versions is getting any
>closer?
GNU Emacs incoroporates many of the features of Lucid Emacs. We are
using sections of Lucid's code, and have benefited from their advice.
.. and have deliberately implemented other features in an
incompatible way, so as better to screw all Emacs users.
We have a Lucid emulation package (lucid.el) which may or may not be
terribly effective; we'll have to see it in use.
Not terribly much. (The real advances in Lucid's code are in areas in
which Stallman has deliberately chosen to implement incompatible
functionality, even given a Lucid precedent.)
The FSF's "lucid.el" consists largely of
* aliases of functions named "*screen*" in Lucid Emacs and Emacs 18
but renamed "*frame*" in FSF 19 (this is a desirable name change,
but I believe the Lucid Emacs authors preferred compatibility
over better nomenclature at the time.) I imagine that Lucid may
change also, given a precedent for user pain.
* a couple of utility Lisp functions which RMS doesn't want in his
small, pure, simple Emacs (eg copy-tree, remove-hook, remprop)
* some functions which it is totally insane not to include as
part of basic Emacs (keymap-parent, map-keymap, etc)
"What's data abstraction anyway?"
* a couple of miscellaneous utilities (eg add-timeout)
Not anything really effective on the whole, I'd imagine, to deal with
the real incompatibilities (the event-stream, faces and extents.)
As far as I can see, RMS' whole course has been to make everything to
do with the real issues as divergent as possible by systematically
substituting worse for better.
Some features of Lucid we will probably never have; Stallman doesn't
like some of them. Since the people with real influence over the
designs of the products (Zawinski, Stallman) are both rather stubborn,
I wouldn't hold my breath for a complete unification.
My aim wasn't a "unification", either because the RMSmacs code is
simply perverse and wrong in many areas (eg events, keymaps) or
because it has diverged (deliberately) too far from Lucid's code for a
simple effort to be made by a non-window-system kind of guy (faces,
screens, etc.)
My aim was to incorporate as many compatible changes made in the FSF
code (many bug fixes, some features, many dubious kludges like
find-file-name-handler) as possible into the exiting Lucid Emacs
distribution, both to take advantage of good work done by FSF Emacs
hackers and to make all future source-compare-and-merge operations
simpler (if anybody has the resolve, technical ability and time to
perform them).
Tom Horsley
mouse is half the time! Until that is fixed (which I am told will be in the
grand display code rewrite to be done real soon now...), I can't use it at
all (in fact I have trouble understanding how anyone can use it). I am just
waiting to see if FSF emacs 19 happens first or the lucid display code
rewrite happens first.
Its all very well to argue about which abstractions provide the most elegant
features, but I'll take a working and useable kludge over a bug filled
elegant implementation any day :-).
Anyway, I am not sure why there is so much heat being generated over this.
If people like the FSF version better, they will use it. If they like the
lucid version better, that's the one they will use. Let the "marketplace"
decide, don't waste time arguing about which is better. (Right now lucid
has a big lead because you can at least get a copy of it).
--
======================================================================
domain: taho...@csd.harris.com USMail: Tom Horsley
uucp: ...!uunet!hcx1!tahorsley 511 Kingbird Circle
Delray Beach, FL 33444
+==== Censorship is the only form of Obscenity ======================+
| (Wait, I forgot government tobacco subsidies...) |
+====================================================================+
Barry A. Warsaw
>>>>> "TH" == Tom Horsley <t...@ssd.csd.harris.com> writes:
TH> But the real problem with lucid is the fact that it can't tell
TH> where the mouse is half the time!
I guess I don't understand what this means? I've never had any
problems visually finding my cursor, or point. I may have to jiggle
my trackball a bit occasionally if there are lots of colors on my
screen, but that's about it.
TH> Its all very well to argue about which abstractions provide
TH> the most elegant features, but I'll take a working and useable
TH> kludge over a bug filled elegant implementation any day :-).
Lemacs (non-beta) is very stable. The Lucid folks have done a great
job. About the only reasons (IMHO) not to just switch to Lemacs right
now are:
1. You need non-X support
2. You don't have the time to do the minimal work necessary to convert
your lisp from 18 to 19 style.
TH> Anyway, I am not sure why there is so much heat being
TH> generated over this. If people like the FSF version better,
TH> they will use it. If they like the lucid version better,
TH> that's the one they will use. Let the "marketplace" decide,
TH> don't waste time arguing about which is better. (Right now
TH> lucid has a big lead because you can at least get a copy of
TH> it).
There's another aspect involved when you start talking about the huge
gobs of contributed lisp code out there. Some pkgs won't be affected
by the change from v18 to v19, others could be considerably affected
and their authors will have to port them. I can tell you as the
c++-mode author that its impossible for me to keep a copy of all
emacsen on my system to verify that when I make a change, it still
works for everyone. Of course, I'll try to use good s/w eng
techniques to isolate the differences, etc, but for example I have to
maintain support for 6 different flavors of emacsen. That leads to
code bloat and it means that I'm more dependent on users to fix bugs
in places I can't test. Where GNU19/Lemacs19 is concerned, RMS's
decision to do things differently adds some lines of code, and some
unnecessary complexity. Here's a quick example:
(defconst c++-emacs-features
(let (mse-spec scanner)
(if (= 7 (length (parse-partial-sexp (point) (point))))
;; vanilla GNU18/Epoch 4
(setq mse-spec 'no-dual-comments
scanner 'v18)
;; we know we're using v19 style dual-comment specifications.
;; All Lemacsen use 8-bit modify-syntax-entry flags, as do all
;; patched GNU18 and Epoch4's. Only GNU19 uses 1-bit flag. this
;; is a bit kludgy since we can't directly query emacs about
;; this feature.
(if (or (string-match "Lucid" emacs-version)
(not (string= (substring emacs-version 0 2) "19")))
(setq mse-spec '8-bit)
(setq mse-spec '1-bit))
;; we also know we're using a quicker, built-in comment scanner,
;; but we don't know if its old-style or new. Fortunately we can
;; ask emacs directly
(if (fboundp 'forward-comment)
(setq scanner 'v19)
(setq scanner 'old-v19)))
;; now cobble up the necessary list
(list mse-spec scanner))
"A list of needed features extant in the emacs you are using.
There are many flavors of emacs out on the net, each with different
features supporting those needed by c++-mode. Here's the current
known list, along with the values for this variable:
Vanilla GNU 18/Epoch 4: (no-dual-comments v18)
GNU 18/Epoch 4 (patch1): (8-bit old-v19)
GNU 18/Epoch 4 (patch2): (8-bit v19)
Lemacs 19.4 - 19.6: (8-bit old-v19)
Lemacs 19.7 and over: (8-bit v19)
GNU 19: (1-bit v19)")
...
;; comment syntax
(cond
((memq '8-bit c++-emacs-features)
;; Lucid emacs has the best implementation
(modify-syntax-entry ?/ ". 1456" c++-mode-syntax-table)
(modify-syntax-entry ?* ". 23" c++-mode-syntax-table)
(modify-syntax-entry ?\n "> b" c++-mode-syntax-table))
((memq '1-bit c++-emacs-features)
;; GNU19 has sub-optimal, but workable implementation
;; Some strange behavior may be encountered. LOBBY FSF!
(modify-syntax-entry ?/ ". 124" c++-mode-syntax-table)
(modify-syntax-entry ?* ". 23b" c++-mode-syntax-table)
(modify-syntax-entry ?\n ">" c++-mode-syntax-table))
(t
;; Vanilla GNU18 is just plain busted. We'll do the best we can,
;; but some strange behavior may be encountered. PATCH or UPGRADE!
(modify-syntax-entry ?/ ". 124" c++-mode-syntax-table)
(modify-syntax-entry ?* ". 23" c++-mode-syntax-table)
(modify-syntax-entry ?\n ">" c++-mode-syntax-table))
)
And c++-mode.el is pretty well self-contained. I shudder to think what
some of the larger package authors are going to have to do (vm, gnus,
calc, etc...)
-Barry
Per Abrahamsen
>>>>> On 21 May 1993 18:17:30 GMT, war...@nlm.nih.gov (Barry A. Warsaw) said:
Barry> 1. You need non-X support
Barry> 2. You don't have the time to do the minimal work necessary to convert
Barry> your lisp from 18 to 19 style.
3. You need outline mode.
When you have started to use outlines to organize programs and
documents, it is very hard to give up.
Outline mode is broken in the alpha version of Emacs 19, but not quite
as badly as in Lucid Emacs.
Barry> And c++-mode.el is pretty well self-contained. I shudder to think what
Barry> some of the larger package authors are going to have to do (vm, gnus,
Barry> calc, etc...)
Well, there are no Emacs 18, Emacs 19, Lucid Emacs, or Epoch
dependencies in AUC TeX. The only code dependencies are for DEMACS,
NEMACS and MULE.
Bill Sommerfeld
>>>>> On 21 May 1993 18:17:30 GMT, war...@nlm.nih.gov (Barry A. Warsaw) said:
Barry> 1. You need non-X support
Barry> 2. You don't have the time to do the minimal work necessary to convert
Barry> your lisp from 18 to 19 style.
3. You need outline mode.
4. You want a minibuffer in a separate window a la epoch (I hacked on
this a bit, but couldn't get it to behave correctly..).
- Bill
James A.Dahlberg 490TX
>But the real problem with lucid is the fact that it can't tell where the
>mouse is half the time! Until that is fixed (which I am told will be in the
>grand display code rewrite to be done real soon now...), I can't use it at
>all (in fact I have trouble understanding how anyone can use it). I am just
I wish you would quit complaining about the mouse problem. It is easily
fixed by installing mode-motion. Since I did that, I haven't had any mouse
problems. You can find mode-motion on ftp.loria.fr:/gnu [152.81.12.10].
Besides mode-motion is VERY useful for the features it adds. I couldn't
live without it :-).
+------------------------------------------------------------------+
| Jim Dahlberg Computing Devices International |
| j...@verdin.cdev.com A Division of Ceridian |
| james.a....@cdev.com |
+------------------------------------------------------------------+
| Through the darkness of futures past / The magician longs to see.|
| One chance out between two worlds / Fire walk with me. |
+------------------------------------------------------------------+