🚀 go-pugleaf

In article <PHR.91Apr13033047@lightning.Berkeley.EDU>, Paul Rubin writes:
In article <1991Apr10.164029.8489@odin.corp.sgi.com> 
portuesi@tweezers.esd.sgi.com (Michael Portuesi) writes:

   GNU has a lot more "out of the box" functionality than Epsilon.  But
   I can't think of a single feature that GNU has that could not be
   implemented in Epsilon's EEL extension language.  Epsilon is a full
   fledged Emacs implementation by every standard Stallman set
   forth a long time ago.  Furthermore, the "out of the box" functionality
   provided by Epsilon covers about 90-95% of the things that I do with
   GNU Emacs.

> I've used Epsilon quite a lot and admire it, but comparing it to GNU
> Emacs is like comparing a bicycle to the space shuttle.

I prefer to think of it as comparing a Honda to a Mercedes.  Both get you
to where you want to go, but at least the Honda still has an engine.  The
Mercedes does it in style.

> Epsilon does *not* contain the EEL extension language, i.e. you cannot
> type EEL expressions at Epsilon and have it interpret them, like you can in
> Emacs Lisp.

True.  So?

> EEL is implemented in a separate program that compiles
> EEL scripts to byte code which you then load into Epsilon.  This makes
> debugging lots of fun.

I'm pretty sure that Epsilon offers some sort of debugging facility,
but I haven't used it and I don't have the manual handy, so I'll
refrain from comment.

> Also, EEL is very similar to C, which for
> writing editor commands, is *not* an advantage.  For example, there is
> no string type--you must use char *'s like in C, and you must malloc
> and free the strings as there is no garbage collector.  (Am I still
> correct?).

This isn't really an argument between Epsilon and Emacs, but one about
Lisp vs. C.  I agree that an interpretive, easily customizable Lisp
environment is better than a compiled language like C for editor
customization.  But the Epsilon approach does involve very little overhead,
and moves much of the extension language away from the main executable
when you're not using it.  About 1% of the time I use my editor is spent
customizing it;  I think it's rather nice that Epsilon doesn't waste memory
keeping the extension language around the other 99%.

Again, let me repeat my original message:  Epsilon is *not* better than
Emacs.  It doesn't pretend to be.  But it certainly doesn't compromise
the essentials in order to be able to run on a 4.77 Mhz 8088 with 256K
memory and a floppy drive (which I think is the smallest configuration
it supports).

> I don't mean to knock Epsilon, just to correct some overstatement.

No problem here.

> To the person who asks whether Epsilon's default keybindings are
> messed up (i.e. "improved" from Emacs's): yes, they, are, but not too
> badly. 

Depends on how you look at it.  The key bindings in Epsilon to some
extent a synthesis between the bindings of Unipress and GNU Emacs,
with some Epsilon-specific things thrown in for good measure.  The
GNU purist may cringe, and even I think the Unipress bindings are
brain-dead, but there's a few in Unipress that are pretty reasonable
(C-z and M-z for scroll-up-one-line and scroll-down-one-line) and
those are the ones that Epsilon picked up upon.  (Myself, I bind
those functions to M-n and M-p in both editors).
__
\/  Michael Portuesi   Silicon Graphics, Inc.   portuesi@sgi.com

"It would be a shame to limit that puppy to four bits." -- John Corbett