Xref: utzoo comp.sys.ibm.pc.misc:8733 comp.sys.laptops:2570 gnu.misc.discuss:2847 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!bionet!agate!agate!phr From: phr@lightning.Berkeley.EDU (Paul Rubin) Newsgroups: comp.sys.ibm.pc.misc,comp.sys.laptops,gnu.misc.discuss Subject: Re: Freemacs or MG2a or Epsilon? Message-ID: Date: 18 Apr 91 10:47:50 GMT References: <1991Apr15.153319.16252@odin.corp.sgi.com> Sender: root@agate.berkeley.edu (Charlie Root) Organization: ucb Lines: 147 In-Reply-To: portuesi@tweezers.esd.sgi.com's message of 15 Apr 91 15: 33:19 GMT 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: 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 "". This is because computers are not used like typewriters. Having 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).