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

Text File | 1992-08-17 | 4.4 KB | 94 lines

Newsgroups: comp.editors
Path: sparky!uunet!usc!sol.ctr.columbia.edu!caen!news.cs.indiana.edu!umn.edu!unet.umn.edu!fin
From: [e-mail] (Craig A. Finseth)
Subject: Re: buffer gap: actually writing an editor
Message-ID: <[e-mail]>
Keywords: Finseth, Craft, Of, Text, Editing
Sender: [e-mail] (Usenet News Administration)
Nntp-Posting-Host: norge.unet.umn.edu
Organization: University of Minnesota, Networking Services.
References:  <fortony.714037868@murphy>
Date: Mon, 17 Aug 1992 14:25:53 GMT
Lines: 80

In article <fortony.714037868@murphy>, [e-mail] writes:
|> Greets!  I just finished reading Finseth's fine _The Craft of
|> Text Editing_ (forty bucks -- cha ching!).  Why?  Well, I'm
    ...
|> 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

Remember that there is a gap between the left and right bits.  When
inserting text, you have to move the gap to the point (i.e., where you
are inserting), then just move a pointer and stuff the character.

The entire right bit would only be moved if you ran out of gap.  For
example, GNU-Emacs moves the entire right bit by at least a Kbyte.  If
you are on a system where such large motions will cause problems, I
suggest using paged buffer gap.

|>     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?

Well, there are three issues here: modes, Lisp, and number of
keypresses.

I consider that the major issue modes is their psychological
complexity.  Now, people _can_ learn to deal with anything.  The
question is, what _should_ they learn.  It is my opinion that modes
should not be present in core operations such as basic editing.

I consider Lisp to be an excellent implementation language.  However,
I do not say that it is the only good language, nor do I say that
every user should be able to program in Lisp.

I am only aware of one study (the Robert's study mentioned in my
bibliography), and was on three ancient editors and TECO (which, oddly
enough, has the same insert / edit modality as vi).

|>     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?

Well, until we get affordable content-addressable disk drives, the
_only_ way to do a linear search through text is to fetch each block
into memory and look at it.  The trick is to maxmize the information
in each block.  Buffer gap does that because, except for the four
block ends, each block is 100% packed with data in the correct order.
Paged buffer gap lowers the data packing to less than 100%, but at
least all the data is in the right order.  Linked line can have
terrible properties, due to interweaving of lines.

Craig A. Finseth            [e-mail] [CAF13]
Networking Services            [phone] desk
Computer and Information Services    [phone] problems
University of Minnesota            [phone] fax
130 Lind Hall, 207 Church St SE
Minneapolis MN 55455-0134, USA