NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/editors/2011

Text File | 1992-08-16 | 3.6 KB | 80 lines

Newsgroups: comp.editors
Path: sparky!uunet!wupost!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!murphy!fortony
From: [e-mail]
Subject: buffer gap: actually writing an editor
Message-ID: <fortony.714037868@murphy>
Originator: fortony@murphy
Summary: an actual article concerning editors! :)
Sender: [e-mail] (Net Noise owner)
Organization: University of Illinois at Urbana
Date: Mon, 17 Aug 1992 07:51:08 GMT
Keywords: Finseth, Craft, Of, Text, Editing
Lines: 66

Greets!  I just finished reading Finseth's fine _The Craft of
Text Editing_ (forty bucks -- cha ching!).  Why?  Well, I'm
going to try to write an editor.  And first, I've got a few
questions.  They're going to be phrased in ANSI C.

    I'm having some problems imagining how I'd implement
the buffer gap method.  Finseth says this is just a big
contiguous block of memory divided into two bits, with
pointers to the beginning and endings of both bits.  Let's
call them the left bit and the right bit.  Now, if I am
in a situation where the left bit is very small (say, a
few lines down from the top of the file) but the right bit
is very large (say, /usr/dict/words), then I can't figure
out why I'm not really in trouble when I insert a character.
The inserted character requires that the right bit be moved
farther right out of the way in memory.  Depending on the
size of the file and the efficiency of the memmove, this
could take a really long time.  And in a modeless editor
such as emacs -- where every typed character must be
immediately added to the buffer -- this would have to
happen every time you pressed a key.  Ideally, you could
sneak the 'left bit' more left to make room for the
inserted character, but decrementing pointers into
unallocated regions of memory is a bad idea, and there
can exist no algorithm to correctly determine how much
memory to preallocate for this purpose.
    But people use emacs every day, some even happily.
I must be missing something.

    My second dilemma is modelessness over modality.
Please restrain all thoughts you may have on this point to
technical discussion.  I'm thinking that modality is
basically 'control-lock'.  Instead of having to type
^F^F^F^F^F^D as per emacs, a user in vi can type
ESCkkkkkj(editing entry key), 'locking' the control key
down until she 'unlocks' it with 'a' or 'r' or 'i' or
whatever.  Finseth thinks this is disreputable behavior
for an editor because users might not be able to figure
out modes -- but he goes on to think that LISP is a great
implementation and extension language which those same
users would be using, so I'm kinda iffy.  Are there any
studies on the average keypresses in, say, vi, versus
the average keypresses (including the first press of
the bucky key[s]) in emacs?

    My third dilemma is emulation of virtual memory.
As a maintainer of sun workstations, I am acutely aware
that sensible programs can swap to disk much more sanely
than the system.  However, increasing the number of
boundaries a search or move can cross seems to get scary,
especially when, as must be the case, the chunks of file
can be of very different sizes.  A user might delete
everything out of a chunk except for the letter 'a',
for instance, and then issue a search for "*aa".  This
would have the potential for seriously spamming the
machine and/or the disk system if the chunk got swapped
out.  What are currently accepted held beliefs concerning
memory usage and well-behaved generic editors?


e-mail to [e-mail] is great, but I
imagine that other editor writers/admirers might
appreciate the answers too.
--
a b c d e f g h i j k l m n o p q r s t u v w x y z
Felix Sebastian Ortony    [e-mail]