Newsgroups: comp.editors
Path: utzoo!utgpu!watserv1!watmath!mks.com!ant
From: ant@mks.com (Anthony Howe)
Subject: Re: REPOST: editor.101
Date: Fri, 14 Jun 91 14:14:50 GMT
Message-ID: <1991Jun14.141450.19678@mks.com>
Organization: Mortice Kern Systems, Waterloo, Ontario, CANADA
References: <1991Jun12.202509.14825@wpi.WPI.EDU> <2857@pdxgate.UUCP> <1991Jun13.154125.6307@informix.com>

cortesi@informix.com (David Cortesi) writes:
>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
[...]

A good liner/pager manager should be able to force line breaks at reasonable
locations like after 1K provided that when the file is saved again that
<newline> characters are NOT added.  I remember mention that Elvis stored
the <newline> in the 1K block.  Does that mean if Elvis splits a long
line it appends a <newline> or it just treats it as a logical <newline>?

If it appends a <newline>, then double yuck!

>The Edit application distributed with the NeXT, however, reads the same
>file just fine; it doesn't care how long lines may be.


-- 
ant@mks.com                                                   Anthony C Howe 
Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9
"Fate favors fools, small children, and ships named Enterprise" - Riker