🚀 go-pugleaf

  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).