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

Internet Message Format | 1992-08-18 | 4.4 KB

Path: sparky!uunet!dtix!darwin.sura.net!rsg1.er.usgs.gov!news.cs.indiana.edu!syscon!gator!fang!att!cbnewsi!cbnewsh!warren
From: [e-mail] (warren.a.montgomery)
Newsgroups: comp.editors
Subject: Re: buffer gap: actually writing an editor
Summary: Make sure it is customizable!
Keywords: Finseth, Craft, Of, Text, Editing
Message-ID: <[e-mail]>
Date: 18 Aug 92 14:23:09 GMT
References: <fortony.714037868@murphy>
Organization: AT&T
Lines: 85

In article <fortony.714037868@murphy>, [e-mail] writes:

>     I'm having some problems imagining how I'd implement
> the buffer gap method.  Finseth says this is just a big
...
> 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
...
You don't move after every insertion, only when the gap is filled
up (or in some schemes not at all).  The performance problem with
buffer gap schemes, if there is one, is that moving around in the
file can require you to move the gap, and that requires copying.
...
>     My second dilemma is modelessness over modality.
> Please restrain all thoughts you may have on this point to
> technical discussion.
...
Sorry, This isn't a technical issue.  I've seen studies supporting
both modal and non-modal editors as being better from a keypress
standpoint, but keyboard efficiency has nothing to do with user
preference or effectiveness.  People basically will want your
editor to behave exactly like the one they learned on.  In the old
days, emacs and vi were the things most users had experienced, if
any, but now there are lots of PC based editors with varying
degrees of Modality that people are likely to have experienced.
The best suggestion is that whatever you do, make it flexible
enough to be rebound.
...
> 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.
...
I don't think the big win is Lisp per-se vs anything else here,
but you need an extension langauge that lets you incrementally
update and dynamically bind new functionality, like lisp, and it
is a big win to have your "built in" commands built on top of the
extension language (something I learned by doing otherwise in my
emacs clone).
...
> What are currently accepted held beliefs concerning
> memory usage and well-behaved generic editors?
...
My first comment is that unless your editor will be used for doing
searches on War and Peace, run on some ancient hardware, or you
did something terribly inefficient in the buffer representation,
virtual memory behavior of the buffer is not likely to be a big
problem for you.  As someone else pointed out, if you search the
whole buffer you have to read it, and the key things are to store
it in a way that minimizes the number of disk blocks to read and
hopefully reads each block only once, which all the sensible
schemes approach pretty well.  There are some other issues to at
least think about:

Large text and "overhead" data space are frequently more annoying
from than the buffer storage, particularly on a machine with lots
of editors running.  In the latter case, making all of the basic
editor shareable is important, and may be trickey if a lot of it
is written in some extension language, since the pages
containing your extension language code may look like writeable
data to the underlying operating system.

Much editing is read-only (using an editor to page through a file
that is never modified).  Avoiding having to copy the file being
edited into your memory space can be a big win in this case, and
is possible for a paged buffer gap or paged list of segments kind
of representation (just page it out of the file itself).

If you do some explicit memory management or use multiple threads,
you may be better able to overlap slow operations to improved the
percieved response.  My emacs clone, for example, starts
repainting the display while reading a large file as soon as it as
enough of the file read to be able to do it, masking the time
required for file reading with the screen painting.

Have fun, editor implementations are a great place to try out all
those things you learned in operating systems and compilers
courses that you normally don't get a chance to apply, because
someone else already did it for you.

--

    Warren Montgomery
    att!iexist!warren