mcglk@blake.acs.washington.edu (Ken McGlothlen) (01/06/89)
Let's get something straight here. First off, I have to applaud Richard
Stallman's effort to get GNU up and running. (True, I have to wonder about
a man who wants to spread a brain-damage-inducing operating system
over the entire world for free, but I understand the drive, and respect
it.)
I was introduced to GNU Emacs some time ago. Heck, I'm using it now. But,
let's face it. I haven't been impressed by what I've seen so far.
Perhaps it's because I haven't gone through the manual as completely as
I should have. Perhaps it's because it's been *years* since I've played
with LISP. Perhaps I've just gotten used to other editors. But the
combination of GNU Emacs and Unix drives me just a little bonkers, not to
mention inducing an almost complete incomprehension of some of the starry-
eyed hackers (word meant in the olden and time-honored sense, thank you--
not the media mutation) who think Emacs is the greatest thing since the
standardized eight-bit byte and ASCII (which IBM still hasn't gotten its
mind around).
I like the idea of GNU Emacs--a fully programmable editor. That's great--
I have no problem with the concept. But the implementation is . . . well,
a bit tedious.
For example, when GNU Emacs first comes up, it not only has to load a
complete editor, but it also has to load a 100K LISP interpreter. I suppose
I shouldn't make this a griping point, but something like this doesn't
exactly insure portability on anything smaller than a mini--particularly
with anything involving classic Intel segmented architecture ("Intel:
Flawed, And Built To Stay That Way"). Which means that, even though I
have source for the thing, it doesn't exactly port to anything I use
every day--only on non-segmented machines with a few meg of memory.
The next thing it has to do is read in--get this--the entire flipping file
into memory. This, in many cases, has a tendency to limit its use to
machines with virtual memory. Heck, most reasonable editors have the
ability to handle some way of only manipulating part of a large file, and
writing out the portions it's not using into a temporary file of some
sort. I suppose this speeds up things, but it's so *sloppy* to assume
virtual memory or small files. On occasion, it's a useful thing to
pull in a huge file, if only to break it up into smaller parts. But in
Emacs, if you don't either (a) have the memory, or (b) have the virtual
memory, you're SOL.
LISP is nice. But you hardly need LISP for a programmable editor. The
designers could have come up with a somewhat abbreviated system to handle
most needs--one that could have fit into a third or so of the space. Sure,
it's spiffy--but is it so useful that it's mandatory? Or am I completely
missing the point?
And finally (at least for this missive): sure, autosaving is handy.
Yup. But infinitely better (at least, in my experience) is a journal
file. Emacs has caught me off my guard more than once through something
like the following: say I've been revising a 200K document, near the
end. I revise the last paragraph, set my mark, and go to the end of
file and delete to mark. Whoops; I went to the beginning of the file
instead. Emacs gives an "autosaving..." message, and my network
connection with the Unix machine chooses to die before I can use the
Undo command.
With a journal file, I'd just come back and edit the journal file first--
removing everything after the last "set mark" command, then recover the
file using the journal file. Instead, I'm stuck with going back to the
backup file, which erases all my changes.
I'm willing to try anything new. And I have this annoying tendency to
listen to my friends. Yet, so far, I have this involuntary gag reflex
that occurs when I use GNU Emacs. Maybe there's something buried deep
within Emacs that will allow me to do everything I want, but at the
moment, I can't find it--and it the meantime, it's driving--me--slowly--
bananas. (* b-b-b-b-b-b-b-b *)
Maybe some pointers? Maybe some good arguments? Heck, I'd love to
be convinced, even if I can't port it to a computer that I use every day.
--Ken McGlothlen
mcglk@blake.acs.washington.edukarl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (01/06/89)
mcglk@blake.acs.washington.edu (Ken McGlothlen) writes:
I like the idea of GNU Emacs--a fully programmable editor. That's great--
I have no problem with the concept. But the implementation is . . . well,
a bit tedious.
I see you've brought your can of worms with you today. Not to mention
your Crusader's sword-and-shield. (Religious war begins? :-)
While I find GNU Emacs to be large and in some sense unwieldy, I don't
criticize it on that basis, because of the amount it does for me.
One can certainly critique unwarranted occupation of large amounts of
memory. No argument from me. However, the obvious general trend in
machines is for ever-larger amounts of it. Really huge amounts. The
opposing trend is this tendency to use too much memory. Some tradeoff
is in order, of course, but given the amount of memory (especially
virtual) that becomes available, the result tends to be more concern
with additional useful function rather than conservation of space.
The next thing it has to do is read in--get this--the entire flipping file
into memory...
I suppose this speeds up things, but it's so *sloppy* to assume
virtual memory or small files.
I consider this to be a large point in Emacs' favor. An editor is
supposed to edit chunks of text, not spend its time worrying over
whether the physical machine can cope with the chunks. That's the
problem of the underlying operating system. Don't re-invent the wheel
by implementing what amounts to a VM system within Emacs; instead, let
{UNIX,VMS,<whatever>} do that work for you. This is exactly the
correct philosophical approach.
LISP is nice. But you hardly need LISP for a programmable editor. The
designers could have come up with a somewhat abbreviated system
If you want an abbreviated version, you can find some other version of
Emacs with such a system. A number exist. But the nice thing about
GNU Emacs is that it really gives you *all* *that* *power*, which you
can put to use if you really need it. Too much power is better than
finding arbitrary limitation. This goes for the LISP implementation
and the VM system - and the VM system should take care of the problem
of not keeping more of the LISP system around than necessary anyway.
And finally (at least for this missive): sure, autosaving is handy.
Indeed it is. Journals -vs- autosaving is kind of a six-of-one-and-
half-a-dozen-of-the-other issue, it seems. The effect is the same
either way you go - protection against system failure. You can put up
with the occasional burst of slowness (ponder that concept a while)
due to autosaving, or you can put up with the continual reduction in
speed by maintaining a journal buffer and flushing it periodically. I
don't see that there's a major preference either way.
If one wishes to argue against having lots of memory, or against
having VM, or in favor of segmented architectures, that's fine; but I
don't think it fits any criteria of desirability or trend in the
industry.
--Karlnelson@sun.soe.clarkson.edu (Russ Nelson) (01/06/89)
In article <490@blake.acs.washington.edu> mcglk@blake.acs.washington.edu (Ken McGlothlen) writes:
LISP is nice. But you hardly need LISP for a programmable editor. The
designers could have come up with a somewhat abbreviated system to handle
most needs--one that could have fit into a third or so of the space. Sure,
it's spiffy--but is it so useful that it's mandatory? Or am I completely
missing the point?
Well, speaking as the author of one of the free PC Emacses (Freemacs),
I can attest to the fact that a somewhat abbreviated system is
probably insufficient. I originally thought that 64K of code space
for Freemacs would be sufficient. Then I started bumping into that
limit. So now I have 256K of code space. Now the limiting factor is
the capital letter used to designate libraries (yes, I know, I was
young and foolish when I decided on *that* convention.)
I have also worked with MicroEmacs, and it's macro language is a hack.
Syntacticly it's very messy. I have also worked with Bill Frolik on
an editor for the HP-3000 that had a macro language. The only
acceptable solution (IMHO) is to *start* with a programming language
and add editor primitives, rather than start with an editor and add a
programming language to it.
So LISP is a system that is probably going to have enough power. Remember that
rms wrote TOPS-20 Emacs, and is conversant with the problems of THAT editor.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
"I saved the whales!" - Rebecca L. Nelson, 3.5 years old, on receiving her
Christmas present of a whale "adoption" certificate. Bless her liberal heart.milgram@paideia.uchicago.edu (Michele Sara Milgram) (01/06/89)
My only other choices right now are vi and ed, which are no comparison. If I were on VMS and could use TPU/EVE, then the differences might not be so great. 1) Not having to switch between command mode & insert/over-write mode is wonderful. It's a pain to be in vi and realize you weren't in insert mode after all. It also takes a moment to realize why nothing happened after you typed ":wq" (didn't get out of insert mode). 2) Auto-save has made life so much easier. I often dial-up & the cats often walk over the other phones .... 3) I have a personal preference to RMAIL (part of GNU Emacs) to Mailx. It's also nice to have the editor alert me when I get mail & to be able to read it without leaving the editor. 4) Multiple buffers, windows, dired, and other features I might have left out .... If the long start-up time bothers you & you actually have to leave GNU Emacs to do something, stop the job & then foreground it. -- Michele Milgram milgram@paideia.uchicago.edu
w-colinp@microsoft.UUCP (Colin Plumb) (01/06/89)
>[The Right Way to write an editor is to start with a language and add >text editing primitives] Actually, I think it's very close to being true that all Real Programs are turing-equivalent. To put it another way, I'm considering using the definition if it doesn't have a powerful macro language, it's not a Real Program. Of course, this disqualifies the Unix kernel, X windows, and a lot of other things, so I need to do a teensy bit of refinement... -- -Colin (uunet!microsof!w-colinp)
patterso@hardees.rutgers.edu (Ross Patterson) (01/07/89)
>I have also worked with MicroEmacs, and it's macro language is a hack. >Syntacticly it's very messy. I have also worked with Bill Frolik on >an editor for the HP-3000 that had a macro language. The only >acceptable solution (IMHO) is to *start* with a programming language >and add editor primitives, rather than start with an editor and add a >programming language to it. This is true in almost any environment. IBM's VM editor, XEDIT, follows the same rule. It provides a rich set of primitives, and allows them to be invoked from the equivalent of the shell, REXX. REXX is a very flexible language, and is used for many purposes in VM. The obvious benefit of using it for writing XEDIT functions (XEDIT calls them "macros", although strictly speaking they aren't) is that there isn't any new programming language to learn. The odds are *very* high that anyone interested in writing an XEDIT function has already written some REXX programs. I presume this is why EMACS uses LISP: The odds are very high, in the AI community, that anyone interested in writing an EMACS function has already written some LISP code. The fact that, except to extend EMACSen, few of us outside that community write LISP on a regular basis seems to have been ignored, if it has been noticed at all. I find it quite a tribute to EMACS' utility that it survives anywhere outside the AI world, despite the handicap of an otherwise rarely used extension language. Ross Patterson Rutgers University Center for Computer and Information Services
mcglk@blake.acs.washington.edu (Ken McGlothlen) (01/07/89)
Wow. I had no idea when I wrote the original article that I had just doused myself in gasoline. Whee. :) Within a very short time, I had eight mail messages that addressed *all* the points I had made (and quite reasonably, too), plus four people who suggested that I be forced to use vi for the rest of my natural life. (No thanks--I don't even *touch* vi.) Not to mention the articles that appeared in this newsgroup, which were surprisingly flame-free. It must be the spirit of the FSF at work; I doubt I would have been able to get away with such an ill-informed posting in any other newsgroup. So, thank you all. I'd like to thank all of you by name, but I have a feeling that I'm going to be receiving mail for the next few days on this. Lessee--yup, two more messages since I started this thing. :) --Ken McGlothlen mcglk@blake.acs.washington.edu