Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!gillies
From: gillies@m.cs.uiuc.edu
Newsgroups: comp.editors
Subject: Re: Orphaned Response
Message-ID: <37200020@m.cs.uiuc.edu>
Date: 15 Jan 90 01:45:00 GMT
References: <129846@sun.Eng.Sun.COM>
Lines: 18
Nf-ID: #R:sun.Eng.Sun.COM:129846:m.cs.uiuc.edu:37200020:000:937
Nf-From: m.cs.uiuc.edu!gillies    Jan 14 19:45:00 1990


>/* Written 11:28 am  Jan  4, 1990 by fin@uh.msc.umn.edu */
> However, it is a (not universally accepted) software axiom that an
> application-writer has better things to do than re-implement the
> operating system.  CP/M did not offer any paged virtual memory
> support.  Hence we did not re-implement anything.  However, a "typical
> workstation environment" (e.g., Sun) offers the virtual memory support
> in hardware.

I think you lose a lot by assuming (1) virtual memory support (2) The
ability for client programs to remap pages, and (3) that the page
replacement scheme will mesh nicely with your editor.

I still haven't seen a good argument why you shouldn't do the editor
with pieces (linked lists of *arbitrary* text stretches -- not lines).
This technique makes NO assumptions on disk/page/block sizes, can make
decent progress with a very small working set, and is unbeatable for
small changes to 50-megabyte 1-line files.