Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ames!mailrus!tut.cis.ohio-state.edu!triceratops.cis.ohio-state.edu!karl From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) Newsgroups: comp.emacs Subject: Re: Okay--I give; why is Emacs so great? Message-ID: Date: 5 Jan 89 22:24:20 GMT References: <490@blake.acs.washington.edu> Sender: news@tut.cis.ohio-state.edu Organization: OSU Lines: 59 In-reply-to: mcglk@blake.acs.washington.edu's message of 5 Jan 89 20:30:37 GMT 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,} 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. --Karl