Xref: utzoo comp.sys.ibm.pc.misc:8615 comp.sys.laptops:2539 gnu.misc.discuss:2837 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!tweezers.esd.sgi.com!portuesi From: portuesi@tweezers.esd.sgi.com (Michael Portuesi) Newsgroups: comp.sys.ibm.pc.misc,comp.sys.laptops,gnu.misc.discuss Subject: Re: Freemacs or MG2a or Epsilon? Message-ID: <1991Apr15.153319.16252@odin.corp.sgi.com> Date: 15 Apr 91 15:33:19 GMT References: Sender: news@odin.corp.sgi.com (Net News) Reply-To: portuesi@tweezers.esd.sgi.com (Michael Portuesi) Organization: Silicon Graphics, Inc., Mountain View, CA. Lines: 74 In article , 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