Path: utzoo!mnetor!tmsoft!dptcdc!jarvis.csri.toronto.edu!snow.white.toronto.edu!cks
From: cks@white.toronto.edu (Chris Siebenmann)
Newsgroups: comp.editors
Subject: Re: why do editors "shrink-wrap" the text?
Message-ID: <89Apr5.154824edt.30755@snow.white.toronto.edu>
Date: 5 Apr 89 19:48:09 GMT
References: <1686@wpi.wpi.edu> <97499@sun.Eng.Sun.COM>
Reply-To: cks@white.toronto.edu (Chris Siebenmann)
Distribution: na
Organization: Ziebmef home away from home
Lines: 28

In article <97499@sun.Eng.Sun.COM> landauer@sun.com (Doug Landauer) writes:
| In other words, I agree with your first sentence more than you do!  I
| hate this notion that programmer's editors (vi & emacs) have of some
| kind of "shrink-wrap" covering the existing text in a file.  My mental
| model of a text file is that it is like a piece of paper.  I move the
| pen (the cursor) and then write stuff there.  *Right there!*.  Not at
| some location that the editor picks because it was easy for the guy who
| designed the editor.

 Here we have a conflict between two basic models of how editors
should work. One school has the view that you are editing the bytes in
the file directly; what you see on the screen is just an approximation
to this (tabs are expanded for your convenience, for example). The
other school holds that what you're editing is a sheet of paper with
the text plunked down on it, so you should be able to scribble in the
margins or in the middle of a tab stop.

 Both views have their virtues (it's easier to make changes in random
places with the paper view, but it's easier to edit a binary file with
the stream-of-bytes view). For better or worse, Emacs-style editors
(and to a lesser extent vi-style editors as well) have chosen the
stream-of-bytes approach.

-- 
	"I shall clasp my hands together and bow to the corners of the world."
			Number Ten Ox, "Bridge of Birds"
Chris Siebenmann		...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks
cks@white.toronto.edu	     or ...!utgpu!{,csri!}cks