Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!nsc!pyramid!infmx!cortesi
From: cortesi@informix.com (David Cortesi)
Newsgroups: comp.editors
Subject: Re: REPOST: editor.101
Message-ID: <1991Jun13.154125.6307@informix.com>
Date: 13 Jun 91 15:41:25 GMT
References: <1991Jun12.143930.14186@mks.com> <1991Jun12.202509.14825@wpi.WPI.EDU> <2857@pdxgate.UUCP>
Sender: news@informix.com (Usenet News)
Organization: Informix Software, Inc.
Lines: 23

In article <2857@pdxgate.UUCP> kirkenda@eecs.UUCP (Steve Kirkendall) writes:
>
>Elvis uses a temporary file for storing the edit buffer.  This file is
>divided into blocks of 1k bytes apiece.  Each block contains one or
>more whole lines; lines are not allowed to straddle a block boundary.

Which means that no line may exceed the block size, or 1K.  Oh,
yuck! I think poorly of editors that put arbitrary limits on line
size.  Let me give you a ferinstance: Frame on the NeXT has this
little bug in the PostScript it generates sometimes, and you can
easily work around it by editing its PostScript output file to
delete a line. But Frame also, sometimes, generates perfectly
legitimate PostScript lines that are 3, 4, 5 kilobytes without a
newline. (PostScript printers do not put arbitrary limits on line
lengths.)  So when I edit one of these doobies with vi, vi will
quit about halfway through the file, croaking "line too long."

The Edit application distributed with the NeXT, however, reads the same
file just fine; it doesn't care how long lines may be.
>
>Now, does anybody want to hear *why* I did it this way?
>
Sure, what's your feeble excuse? (;-)