🚀 go-pugleaf

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.

--Karl