Path: utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU
From: Ralf.Brown@B.GP.CS.CMU.EDU
Newsgroups: comp.sys.ibm.pc
Subject: Re: Editors and huge files
Message-ID: <25ed0b6b@ralf>
Date: 1 Mar 90 10:45:47 GMT
Sender: ralf@b.gp.cs.cmu.edu
Organization: Carnegie Mellon University School of Computer Science
Lines: 24
In-Reply-To: <2470@uudell.dell.com>

In article <2470@uudell.dell.com>, randy@uutopia.dell.com (randy) wrote:
}In article <3658@plains.UUCP>, cooper@plains.UUCP (Jeff Cooper) writes:
}> I'm looking for a editor that can work with HUGE (2 meg) files.  
}
}You don't state the particulars of your needs, but I would like to
}suggest Brief.  I have used in in program development and repairing
}damaged files.  In the case of the latter, Brief is particularly
}effective as it will also edit lines of 512 characters.  It has macros

Only 512 characters?  Sprint will handle arbitrarily long lines--when I first
bought it, I made up a test file consisting of a single 70,000-character
line.  Sprint handled it just fine (except that the column count overflowed
its 16-bit counter).  Although I've never had occasion to edit multi-meg
files, Sprint does handle files much larger than available memory.  I regularly
edit a 600K file in a 250K partition under DESQview....


--
UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask
ARPA: ralf@cs.cmu.edu  BIT: ralf%cs.cmu.edu@CMUCCVMA  FIDO: Ralf Brown 1:129/46
"How to Prove It" by Dana Angluin              Disclaimer? I claimed something?
14. proof by importance:
    A large body of useful consequences all follow from the proposition in
    question.