howcome@media-lab.media.mit.edu (Hakon Lie) (04/10/91)
In article <1991Apr9.224504.26706@demott.com> kdq@demott.com (Kevin D. Quitt) writes: In article <1991Apr9.171225.663@odin.corp.sgi.com> portuesi@tweezers.esd.sgi.com (Michael Portuesi) writes: >In article <HOWCOME.91Apr8165325@media-lab.media.mit.edu>, Hakon Lie >writes: >> there. I realize that Epsilon may run counter to rms' policies, but >> I'm prepared to take the moral consequences of actually *buying* >> something GNU-like. >> >>It's a waste of money, the GNU products are in most cases superior to >>the commercial versions. If they aren't -- someone (maybe you) will >>make them better.. > >I don't understand what you're talking about. Unless you have a >386 or better, you are never going to get GNU Emacs to run on your >laptop. Other than that, Epsilon has far, far more features and >far more extensibility than every public-domain editor available. There is no doubt that GNU-emacs requires performace. However, that doesn't make it an inferior editor. It requires performace because it does a lot of things other editors won't do. Including Epsilon. How can you claim that an editor without an undo facility has "far more features" ? I would pay $1000 for Epsilon, and I wish the damn thing were available for all machines (like my non-intel-processor-based UNIX systems) because it beats the hell out of not only every other editor I've tried, but out of emacs too (IMNSHO). I am seriously interested in how you came to this conclusion. -h&kon -- _____ Hakon W Lie / howcome@media-lab.media.mit.edu ----MIT Media Lab--- (617)253-0312 ----an ec ----s s hnocracy---- ----o ti c tute-of--- hi stic--
john@jwt.UUCP (John Temples) (04/10/91)
In article <HOWCOME.91Apr9210555@media-lab.media.mit.edu> howcome@media-lab.media.mit.edu (Hakon Lie) writes: >How can you claim that an editor without an undo facility has "far more >features" ? Epsilon has had undo/redo since version 4.0. The current release is at 5.0x. Lugaru's support for Epsilon is quite good. I recently upgraded from version 4 to version 5, and found a display refresh bug. I called Lugaru, they were able to duplicate the problem, and I had a new release in my hands within a week. Another point in Lugaru's favor: they let me go from the 286 UNIX version to the 386 UNIX version at the upgrade price, rather than making me buy a new copy. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
portuesi@tweezers.esd.sgi.com (Michael Portuesi) (04/10/91)
Hakon Lie writes: >portuesi@tweezers.esd.sgi.com (Michael Portuesi) writes: >>In article <HOWCOME.91Apr8165325@media-lab.media.mit.edu>, Hakon Lie >>writes: >>>It's a waste of money, the GNU products are in most cases superior to >>>the commercial versions. If they aren't -- someone (maybe you) will >>>make them better.. >> >>I don't understand what you're talking about. Unless you have a >>386 or better, you are never going to get GNU Emacs to run on your >>laptop. Other than that, Epsilon has far, far more features and >>far more extensibility than every public-domain editor available. > There is no doubt that GNU-emacs requires performace. Of course not. I use it on my workstation all the time and I love it. It's a great editor. But at the very least you need at least a 386 and lots of memory to make it run on a PC, and even then it would have to run as a protected-mode program under Windows or extended DOS or something. To my knowledge, nobody has done that port. > However, that doesn't make it an inferior editor. Nobody said that GNU was an inferior editor to anything, including Epsilon. My point is that there is no publically available editor for the PC which can match Epsilon for features and flexibility, including Freemacs, MicroEmacs, mg, Jove, etc. etc. If you manage to produce a 386 extended-mode port of GNU emacs and offer to buy me a Toshiba 2000SX to run it on, perhaps I might switch to GNU. But Epsilon is a powerful editor which runs well on the hardware it was designed for, and makes good use of every system resource available (supports EMS, swaps large files to disk, supports all display devices, etc). It runs fine on my T1000XE with a 10 Mhz 8086. GNU Emacs does not. > It requires performace because it does a lot of things other editors > won't do. Including Epsilon. 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. > How can you claim that an editor without an undo facility has > "far more features" ? Epsilon has offered a multi-level Undo facility comparable to that in GNU Emacs for a while now. > I am seriously interested in how you came to this conclusion. Have you actually used Epsilon? m. __ \/ Michael Portuesi Silicon Graphics, Inc. portuesi@sgi.com "Republicans understand the importance of bondage between a mother and child." -- Vice President Dan Quayle
kdq@demott.com (Kevin D. Quitt) (04/11/91)
In article <HOWCOME.91Apr9210555@media-lab.media.mit.edu> howcome@media-lab.media.mit.edu (Hakon Lie) writes: >In article <1991Apr9.224504.26706@demott.com> kdq@demott.com (Kevin D. Quitt) writes: > >How >can you claim that an editor without an undo facility has "far more >features" ? Epsilon has had undo and redo for at least two years now. > I would pay $1000 for Epsilon, and I wish the damn thing were > available for all machines (like my non-intel-processor-based UNIX > systems) because it beats the hell out of not only every other editor > I've tried, but out of emacs too (IMNSHO). > >I am seriously interested in how you came to this conclusion. Because the extension language is C, not Lisp. I can take a program from the net that does something really neat, and directly compile it into my editor. Also because of the customer support from Lugaru. I've been at this game for over 20 years now (frightening thought), and I've used dozens of different editors (including emacs)- none of them can touch Epsilon. On my current UNIX machine, emacs is 5MB on disk, and what's without anything loaded. The loading process takes over a minute. Emacs with everything loaded is 8MB on my machine, and my 8MB RAM system can't even load it! Epsilon is <80K, with another 80K for its state file. Emacs can do things that Epsilon can't, but most of that is because it's running under UNIX and not constrained by DOS. (You *can* run a process in an Epsilon buffer.) I haven't used the (386)UNIX version of Epsilon, but I can't see how there's anything it couldn't do. (Want a newsreader? Don't write one in lisp, import trn or nn code directly into Epsilon!) -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
swansonc@acc.stolaf.edu (Chris Swanson) (04/13/91)
>>>>> On 10 Apr 91 18:56:42 GMT, >>>>> in message <1991Apr10.185642.3208@demott.com>, >>>>> kdq@demott.com (Kevin D. Quitt) wrote: kdq> In article <HOWCOME.91Apr9210555@media-lab.media.mit.edu> howcome@media-lab.media.mit.edu (Hakon Lie) writes: >In article <1991Apr9.224504.26706@demott.com> kdq@demott.com (Kevin D. Quitt) writes: [bunch of stuff deleted] kdq> I've been at this game for over 20 years now (frightening kdq> thought), and I've used dozens of different editors (including kdq> emacs)- none of them can touch Epsilon. On my current UNIX kdq> machine, emacs is 5MB on disk, and what's without anything kdq> loaded. The loading process takes over a minute. Emacs with kdq> everything loaded is 8MB on my machine, and my 8MB RAM system kdq> can't even load it! Epsilon is <80K, with another 80K for its kdq> state file. [more stuff deleted] What "Unix" are you running that does not impliment some kind of paged or virtual memory? Also, what are you loading into emacs? everyting ever written in elisp?? Right now I am running Emacs w/ all the stock, plus MH and GNUS as well as about 20 other pacakges on a NeXT and my `ps` just reported that I am using 2.05M real memory, and have a total requirement (virtual memory) of 3.09M I know it's alot compared to Epsilon, and I'm sure that Epsilon is a nice editor, but your claims of Emacs using > 8 MB of RAM is somewhat high in my book. I agree that Emacs may be a bit much for a low-end PC system, but let's not slam it out of hand, ok? kdq> -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics kdq> Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) kdq> 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last kdq> 96.37% of all statistics are made up. -Chris -- Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057 DDN: (CDS6) INTERNET: swansonc@acc.stolaf.edu UUCP: uunet!stolaf!swansonc AT&T: Work: (507)-645-4528 Home: (507)-663-6424 I would deny this reality, but that wouldn't pay the bills...
phr@lightning.Berkeley.EDU (Paul Rubin) (04/13/91)
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. 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. 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. 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?).
I don't mean to knock Epsilon, just to correct some overstatement.
Epsilon actually runs reasonably fast on a *4.77 MHz* Toshiba T1000,
and it is small enough to leave in the ramdisk all the time.
Brief is way too slow for such machines, besides being a lot bigger.
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. JOVE messes them up considerably more. MG tries to remain
faithful, though they messed up in a few places too, sometimes by
accident.
By the way, has anyone ported ELLE to MS-DOS?
miles@cogsci.ed.ac.uk (Miles Bader) (04/14/91)
phr@lightning.Berkeley.EDU (Paul Rubin) writes: > 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. JOVE messes them up considerably more. MG tries to remain > faithful, though they messed up in a few places too, sometimes by > accident. Actually, epsilon does an incredible job of picking the best keybindings from both the original emacs and gosling's emacs-- by far the best default set I've ever used. None of this ``We must follow the holy bindings chosen by RMS'' shit. [Note that the last version of epsilon I used was something like 1.0x... At the time, I used Twenex emacs a lot more than Gosling's.] -Miles -- -- Miles Bader -- HCRC, University of Edinburgh -- Miles.Bader@ed.ac.uk
kdq@demott.com (Kevin D. Quitt) (04/15/91)
In article <SWANSONC.91Apr12175820@grendel3.acc.stolaf.edu> swansonc@acc.stolaf.edu (Chris Swanson) writes: > >What "Unix" are you running that does not impliment some kind of paged >or virtual memory? I'm running on Motorola's Delta 3600 system, SYSV R3.2, and it has virtual memory. >I know it's alot compared to Epsilon, and I'm sure that Epsilon is a >nice editor, but your claims of Emacs using > 8 MB of RAM is somewhat >high in my book. I have acknowleged that those numbers are excessive (but they are correct). I had to do the port to my system based on the documentation in emacs, and it's entirely likey that it was not done correctly. On the other hand, I have, and do use emacs on other systems. >I agree that Emacs may be a bit much for a low-end PC system, but >let's not slam it out of hand, ok? I'm not slamming emacs - if I didn't like it, I wouldn't like epsilon. I just prefer epsilon. And to answer another note about being able to enter extension language directly into epsilon: EEL is compiled, not interpreted. You can edit the eel file, compile it (from within epsilon), and load the compiled code in, making it available and active. I have a function that does precisely that. And while C may or may not have an advantage over lisp for string work, most folks I know can program a lot better in C than they can in lisp. I can program in lisp, I just don't like to. Finally, I do not mean to say in absolute terms: "epsilon is better than emacs". I just much prefer it. -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
portuesi@tweezers.esd.sgi.com (Michael Portuesi) (04/15/91)
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
ab2r@quads.uchicago.edu (Marshall Abrams) (04/16/91)
C/Lisp--compiled/interpreted?: Yeah, some of us prefer Lisp, but most people seem to like C. But for the purpose of running on a slow machine, a compiled extension language is essential. My guess is that what makes Brief and Freemacs so slow is that they don't compile to binary code. This can be a big liability when most of the editor is written in the extension language. I suppose GNU would be at least as bad on an 8088, if it could be run at all.
phr@lightning.Berkeley.EDU (Paul Rubin) (04/18/91)
From: miles@cogsci.ed.ac.uk (Miles Bader) In-reply-to: miles@cogsci.ed.ac.uk's message of 14 Apr 91 12:16:04 GMT Actually, epsilon does an incredible job of picking the best keybindings from both the original emacs and gosling's emacs-- by far the best default set I've ever used. None of this ``We must follow the holy bindings chosen by RMS'' shit. I don't think the Emacs bindings are holy, just that they are STANDARD. How would you like it if the default configuration of Epsilon mapped all the alphabetic keys to a Dvorak layout? That is considered an improvement over qwerty, but it would confuse the hell out of nearly everyone. I also do not think the rebindings (Gosling's or Epsilon's) are improvements. Some are slightly better, some are worse, some are neutral. All are gratuitous attempts to foist off the implementers' personal preferences where a perfectly useable standard existed. If users want to rebind the keys, they can do it themselves, that's what extensibility is for. I think that vendors offering bindings that they think are improvements is a fine idea, as long as they are options that users can activate if they want to. They should not be the DEFAULT so users have to figure out how to change them to be what they are used to. (At least, the vendor should supply a compatibility file). From: portuesi@tweezers.esd.sgi.com (Michael Portuesi) writes: Date: 15 Apr 91 15:33:19 GMT [phr: one can't type EEL expressions at Epsilon ...] True. So? So there's an Emacs feature that some people use frequently, that can't be implemented in EEL in a reasonable way. I often find myself typing Lisp expressions to Emacs for one reason or another. ...I can't think of a single feature that GNU has that could not be implemented in Epsilon's EEL extension language.... That is true, EEL can simulate a turing machine, but Emacs Lisp is a lot more convenient to program in. If you want to see a REALLY inconvenient extension language, try Micro Emacs, for which I think you can also write any extension (I haven't tried). The language is a cross between Forth and assembler, I think. If the ability to implement any feature is all that matters, one doesn't need an editor at all---just a compiler with which you can write your own editor! Emacs extensions I don't expect anyone to reimplement in EEL (though who knows): - Info system/Texinfo converter - smart language indenters (Epsilon has a C mode but it doesn't do nearly as much as Emacs's unless it's been improved) - Desk calculator with arbitrary precision arithmetic, scientific functions, symbolic algebra, and matrices - Bitmap font editor - Gnus reader [to person wanting to compile rn.c with EEL: good luck] - Eliza program - any extension needing lots of subprocess control, like GDB mode (Epsilon has a few such commands but I don't think they're written in EEL; this is mainly because of DOS weakness though) - abbrev mode (has some C hooks in Emacs); dynamic abbrevs - (under construction) graphics editor with user-definable objects (certain kinds of users will make heavy use of having the lisp interpreter available at all times for this) - byte compiler for editor's extension language Some of these may sound like strange things to write as editor extensions, but they were done that way because it was more convenient to write them in Emacs Lisp than in C, which goes to prove the advantage of Lisp for programming ease. > Also, EEL is very similar to C, which for > writing editor commands, is *not* an advantage.... This isn't really an argument between Epsilon and Emacs, but one about Lisp vs. C. Using a C-like-syntax for an editor extension language isn't a bad idea for an editor extension language if it makes users more comfortable. Reproducing all the *warts* of C seems going a bit too far. It would be more reasonable to make a language that looked like C but was better suited to the purpose, in the spirit of `awk'. The way I heard the story, the author of Epsilon first decided to write a C compiler, got as far as the front end and put it aside, later wrote a nonextensible editor, then decided that it needed an extnesion language and had this C front end sitting around... > 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,... I agree that some of their choices may be slight improvements, but not enough to justify creating incompatibility, as said above. If they wanted to redesign the whole command set and not call the editor Emacs-like, fine. If they want to offer their suggested improvements in an alternative setup file, fine. But to make an almost-compatible command set the default is maddening. What they did to ^T and ^V drives me nuts all the time (and before anyone complains about the illogic of ^U^V scrolling the screen 4 lines instead of 4 screens in emacs: it was the result of opinion polls showing that most respondents preferred that behavior. I doubt if whoever changed it conducted any polls before doing so). From: ab2r@quads.uchicago.edu (Marshall Abrams) Date: 15 Apr 91 20:27:34 GMT Yeah, some of us prefer Lisp, but most people seem to like C. But for the purpose of running on a slow machine, a compiled extension language is essential. ... Last I heard, Eel was not compiled to machine code, but to byte code, just like Emacs Lisp. From: <forgot, didn't save original msg> Emacs takes 8 meg of memory... (later: no, less) I used to use Emacs on a 2-meg Vax 11/750 all the time. That machine is comparable to a 386sx laptop in memory and cpu speed. Note that for most such laptops, for the $195 that Epsilon costs, you can buy an extra 2 meg of memory instead. Then you can run Emacs, and the memory can be used for other things too. Move emacs-vs-epsilon discussion to comp.editors, maybe? ***** [new topic, finally]: ***** Since this is comp.sys.laptops and not comp.editors I feel obliged to get slightly back on the subject by saying the one exception to my remarks on messing up the keybindings: departing from standards is ok (IMHO) when the usage pattern of the new thing is different from the old thing. In particular, I feel the "caps lock" key on laptop keyboards is semi-useless and that the key immediately to the left of "A" should always be "<control>". This is because computers are not used like typewriters. Having <control> accessible makes Emacs a lot nicer to use, for example. In Emacs, when I want to enter a region of text in all caps, I usually enter it in mixed case (easier to read what I'm typing), then use upcase-region to upper-casify it. Unfortunately, I see most of the less expensive new 386sx laptops have the bad placement of the control key (expensive ones, like Toshiba, do it right). If any laptop manufacturers are out there, please take note! At least it should be user selectable somehow (not just in the BIOS as some programs actually read the keyboard scan codes).
msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) (04/20/91)
Somehow I don't think the people on the two sides of this argument are arguing about the same thing. I like GNU Emacs. I really do. I use it on the university Sequent I'm posting this from. But it doesn't run under mess-dos. I can't afford to go out and buy a big disk, more ram, and then spend $500--$1000+ for unix. I'd like to run unix on my machine, and when I can afford to do so, I will. And I'll use GNU Emacs as my editor. Right now I use Qedit. It is inexpensive, fast, works reasonably well, and I hacked the keybinding file to sort-of resemble GNU Emacs so I don't go nuts switching from unix to mess-dos and back. I've played with most of the free Emacs-like editors for dos, and I don't like any of them too much. But I'm still looking around. -- < Michael Pereckas <> m-pereckas@uiuc.edu <> Just another student... > "This desoldering braid doesn't work. What's this cheap stuff made of, anyway?" "I don't know, looks like solder to me."
woo@pioneer.arc.nasa.gov (Alex Woo RAA) (04/22/91)
Can someone tell me where is the best place to purchase Epsilon? We have just had a bad experience trying to purchase an Epsilon update directly from Lugaru Software, Ltd. Thanks. ======================================================================== Alex Woo, MS 227-6 woo@ames.arc.nasa.gov NASA Ames Research Center __o NASAMAIL ACWOO Moffett Field, CA 94035-1000 -\<, SPANET 24582::WOO (415) 604-6010 (FAX) 604-4357 .....O/ O {hplabs,decwrl,uunet}!ames!woo ======================================================================== ======================================================================== Alex Woo, MS 227-6 woo@ames.arc.nasa.gov NASA Ames Research Center __o NASAMAIL ACWOO Moffett Field, CA 94035-1000 -\<, SPANET 24582::WOO (415) 604-6010 (FAX) 604-4357 .....O/ O {hplabs,decwrl,uunet}!ames!woo ========================================================================