rotheroe@convexs.UUCP (04/02/87)
I know it was discussed recently, but I didn't pay attention then, and
can't find anything in the last ~150 notes now.
Anyone have or know of a text editor which can edit 100-500k (usually ~150k)
ascii files. IBM's writing assistant and PC-write both seem to have a 64k
limit on file size - ugh - maybe I should have bought a mac (sorry, wrong
newsgroup & too early in the morning).
Thanks in advance,
Dave Rotheroe {allegra, ihnp4, uiucdcs, ctvax}!convex!rotheroe
CONVEX Computer Corporation
Richardson, TX
"Good afternoon, gentlemen. I am a HAL 9000 computer. I became operational
at the Hal plant in Urbana, Illinois, on the twelfth of January, 1992."
2001 & 2010 (book only for 2010)anderson@uwmacc.UUCP (04/03/87)
In article <119200008@convexs>, rotheroe@convexs.UUCP writes: > Anyone have or know of a text editor which can edit 100-500k (usually ~150k) > ascii files. IBM's writing assistant and PC-write both seem to have a 64k > limit on file size - ugh - maybe I should have bought a mac (sorry, wrong > newsgroup & too early in the morning). Available from the SIMTEL20 archives and from a number of bulletin boards around the country is a first-rate Ascii text editor called QEdit. Look for file QEDIT130.ARC. If memory serves me right, the correct Simtel20 directory is PD:<MSDOS.TEXT-EDITORS>, but you may have to poke around a bit if you go that route. One BBS that I know has it is the University of Wisconsin Microcomputer Information Center, 608/263-6057 (2400/1200/300, N/8/1) [same filename there]. QEdit accepts any file that will fit in all of your remaining memory. It also lets you simultaneously edit as many files as you like (subject to the same memory limit), with one-button switch to the next one in the chain. Also, you can have one or two windows looking into the chain of files. Includes a very flexible configuration utility to put commands on any key (I used this to put the 40 most common commands on the function keys; I wish all programs could be configured as easily!) The documentation is a reference manual, not a tutorial, but it's not hard to learn to use. Standard disclaimers. I am a registered user of QEdit. -- ==ARPA:==============anderson@unix.macc.wisc.edu===Jess Anderson====== | UUCP: {harvard,seismo,rutgers, (avoid ihnp4!) 1210 W. Dayton | | akgua,allegra,usbvax}!uwvax!uwmacc!anderson Madison, WI 53706 | ==BITNET:======================anderson@wiscmacc===608/263-6988=======
sdh@inuxm.UUCP (04/03/87)
> Anyone have or know of a text editor which can edit 100-500k (usually ~150k) > ascii files. IBM's writing assistant and PC-write both seem to have a 64k > limit on file size - ugh - maybe I should have bought a mac (sorry, wrong > newsgroup & too early in the morning). The vi editor that comes with the MKS toolkit can edit very large files. The only limit given in the documentation is 50K lines. I have edited files of around 140K bytes. Things slow down with a file that large, but everything works. Stephen Hoskins AT&T Consumer Products Labs. Indianapolis, IN.
samlb@well.UUCP (04/03/87)
In article <119200008@convexs> rotheroe@convexs.UUCP writes: >Anyone have or know of a text editor which can edit 100-500k (usually ~150k) >ascii files. W * o * r * d * S * t * a * r -- Sam'l Bassett, Self-Employed Writer -- My words & ideas are my own! 34 Oakland Ave., San Anselmo CA 94960; (415) 454-7282 UUCP: {...known world...}!hplabs OR ptsfa OR lll-crg!well!samlb; Compuserve: 71735,1776; WU Easylink ESL 6284-3034; MCI SBassett
perkins@bnrmtv.UUCP (04/03/87)
> Anyone have or know of a text editor which can edit 100-500k (usually ~150k) > ascii files. IBM's writing assistant and PC-write both seem to have a 64k > limit on file size - ugh > > Dave Rotheroe {allegra, ihnp4, uiucdcs, ctvax}!convex!rotheroe A good PC editor is Epsilon, from Lugaru Software in Pittsburgh. If you know EMACS, you can be proficient in Epsilon very quickly. It lists for $195. -- {hplabs,amdahl,3comvax}!bnrmtv!perkins --Henry Perkins It is better never to have been born. But who among us has such luck? One in a million, perhaps.
mobo@sphinx.UUCP (04/04/87)
In article <535@inuxm.UUCP> sdh@inuxm.UUCP (Stephen Hoskins) writes: >> Anyone have or know of a text editor which can edit 100-500k (usually ~150k) >> ascii files. > >The vi editor that comes with the MKS toolkit can edit very large files. > I have done 300K files in Wordperfect, but always found it easier to do is in <100K chunks and join it at the end. Samuel Wilson ..ihnp4!gargoyle!sphinx!mobo FOTMOBO@UCHMVS1.Bitnet University of Chicago, Division of Social Sciences
gervers@utgpu.UUCP (04/04/87)
There is one editor that will even edit 2 meg text files. Surprise : it's called wordstar.
pavlov@hscfvax.UUCP (04/04/87)
In article <119200008@convexs>, rotheroe@convexs.UUCP writes: > > Anyone have or know of a text editor which can edit 100-500k (usually ~150k) > ascii files. IBM's writing assistant and PC-write both seem to have a 64k > limit on file size ....... The MKS Toolkit has an excellent implementation of vi; cost, apx $135 US. Vi is actually only a minor part of the package, which also includes much of what is usually described in section 1 of the Unix man pages. It should be a good buy for you, since I would guess that text utilities such as grep might be useful to you cas well ......... greg pavlov, fstrf, amherst, ny
wtm@neoucom.UUCP (04/05/87)
Hi, Mortise Kern System's toolkit includes an implementation of *nix vi editor. It's a pretty good knock-off of the real thing. They also have an implementation of ctags, and even ksh for the PeeCee. I forget the price, but the toolkit packs a lot of goodies for the buck. The documentation is pretty good (Unix like) which means that traditional PeeCee users would likely hate the manual. Well, the point is that I've used MKS's vi to edit things up to 300K in size. That ought to do it. MKS also listens to this newsgroup (hi guys). Bill Mayhew Division of Basic Medical Sciences Northeasetern Ohio Universities' College of Medicine Rootstown, OH 44272 USA phone: 216-325-2511 (wtm@neoucom.UUCP ...!cbatt!neoucom!wtm)
sbanner1@uvicctr.UUCP (04/06/87)
In article <119200008@convexs>, rotheroe@convexs.UUCP writes: > Anyone have or know of a text editor which can edit 100-500k (usually ~150k) > ascii files. IBM's writing assistant and PC-write both seem to have a 64k > limit on file size - ugh - maybe I should have bought a mac (sorry, wrong > newsgroup & too early in the morning). The best one I have come across for that is the version of VI from the MKS toolbox. This version is a very complete version of vi (I have seen a few buggs, but the version I have is NOT the most recent). This version not only gives you everything you are used to with standard UNIX VI, (including ^Z), but you can edit any file that you have sufficent disk space to hold a temporary buffer of (just like UNIX, WOW!! :-). One problem though, I have only once came to the limit of my disk space (I had about 1Meg free on my hard drive at the time, and was editing a file that was about 1.5Meg), and it crashed real good. I don't remember just what happened, but I didn't lose the file (though I don't remember if that was because I had backups or not, I wouldn't be supprised if I didn't; YOU put that on a floppy...). Anyhow, it is FAST, complete, and will edit just about anything (how often do you have to edit a file that won't fit on your hard-drive twice...). Note: the VI from the MKS toolbox is the ONLY PC editor that I have encountered that will edit a file that won't fit in memory (all at once I mean). I have encountered several versions of VI for the PC, and quite a number of other editors that I like, but this is the only one that will do the disk buffering. S. John Banner UUCP ...!{uw-beaver,ubc-vision}!uvicctr!sol!sbanner1 BITNET ccsjb@uvvm ARPA sbanner1@sol.UVIC.CDN #1 1121 Fort St. Victoria BC. Canada V8V 3K9
root@hobbes.UUCP (04/06/87)
+---- rotheroe@convexs.UUCP writes in article <119200008@convexs> ---- | | Anyone have or know of a text editor which can edit 100-500k (usually ~150k) | ascii files. | | Dave Rotheroe {allegra, ihnp4, uiucdcs, ctvax}!convex!rotheroe +---- I hate to drag up a program better left dead, but I've used WordStar 3.3 to edit files larger than 15 Megabytes! (Don't do many Jump to End/Beginnings :-) It works, but it's temp file eats disk space ( Temp file is same size as orig file so total used = 15Mb + 15Mb = >30Mb) This was on an AT with a 120Mb Maxtor hard drive. John -- John Plocher UUCP: <backbone>!uwvax!uwmacc!hobbes!plocher ============== Internet: plocher%hobbes.UUCP@uwvax.WISC.EDU FidoNet: 121/0 BITNET: uwvax!uwmacc!hobbes!plocher@psuvax1
jvc@mirror.UUCP (04/06/87)
+---- rotheroe@convexs.UUCP writes in article <119200008@convexs> ---- | | Anyone have or know of a text editor which can edit 100-500k (usually ~150k) | ascii files. | | Dave Rotheroe {allegra, ihnp4, uiucdcs, ctvax}!convex!rotheroe +---- Solution Systems BRIEF can handle files of any size (maximum line length of 512). It's a programmers editor with many useful features. You can find the ads in most computer magazines (I know its in PC Tech journal and Computer Language). ------------------------------------------------------------------------- Jim Champeaux jvc@mirror.TMC.COM {mit-eddie, ihnp4, wjh12, cca, cbosgd, seismo}!mirror!jvc Mirror Systems, 2067 Massachusetts Avenue, Cambridge, MA 02140 Telephone: (617) 661-0777
mojo@micropro.UUCP (04/07/87)
In article <103@hobbes.UUCP> root@hobbes.UUCP (John Plocher) writes: >I hate to drag up a program better left dead, but I've used WordStar 3.3 to >edit files larger than 15 Megabytes! (Don't do many Jump to End/Beginnings :-) >It works, but it's temp file eats disk space ( Temp file is same size as orig >file so total used = 15Mb + 15Mb = >30Mb) This was on an AT with a 120Mb >Maxtor hard drive. Any of the WordStar versions will handle file sizes limited by disk space only. (WordStar 4.0 includes some nifty program editing features even, like variable tab widths and autoindent.) Here's a little known tip: There are actually two WordStar temporary files. Your original file is only read from, and becomes the .BAK file. As you move forward through the file buffer spills become a temporary file that grows as you cursor forward -- and this file becomes the new file. If you make changes early in your file, move forward, then move backward, another temporary file is created (called EDBACKUP.$$$ in ws 3.3). So the nominal space required on your disk for editing a file with WordStar is free space equal to or greater than twice the size of your original file. However, if you don't back up through the file, the BACKUP temp file isn't needed, and you can edit a large file using only as much free space as the size of your original file. -- Mojo mojo@micropro.UUCP ... Morris Jones, MicroPro Int'l Corp., Product Development {lll-crg,ptsfa,dual,well,pyramid}!micropro!mojo Not the opinion of MicroPro!
rotheroe@convexs.UUCP (04/07/87)
help, I'm lost in billions of bit of mail
Seriously, thanks to the many, many people who sent me a response. Many
people recommended microemacs 3.8, and since it is public domain, I'm going
to try it first. Thanks again,
Dave Rotheroe {allegra, ihnp4, uiucdcs, ctvax}!convex!rotheroe
CONVEX Computer Corporation
Richardson, TX
"Good afternoon, gentlemen. I am a HAL 9000 computer. I became operational
at the Hal plant in Urbana, Illinois, on the twelfth of January, 1992."
2001 & 2010 (book only for 2010)johnl@ima.UUCP (04/08/87)
In article <119200008@convexs> rotheroe@convexs.UUCP writes: >Anyone have or know of a text editor which can edit 100-500k (usually ~150k) >ascii files. ... I always use Epsilon from Lugaru Software, 412-421-5911. I have no idea how big a file it can edit because my hard disk always fills up first. A megabyte is no problem. I've also used it to patch a 600K binary file. It's the fastest PC editor I've ever used, and doesn't slow down too badly as the file gets big. It has lots of features and options, and an extension language that looks just like C, but unlike some overfeatureful editors, the authors paid a lot of attention to getting the basic editing right. -- John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something Where is Richard Nixon now that we need him?
catone@dsl.cis.upenn.edu.UUCP (04/08/87)
In article <119200008@convexs> rotheroe@convexs.UUCP writes: > >I know it was discussed recently, but I didn't pay attention then, and >can't find anything in the last ~150 notes now. > >Anyone have or know of a text editor which can edit 100-500k (usually ~150k) >ascii files. IBM's writing assistant and PC-write both seem to have a 64k >limit on file size - ugh - maybe I should have bought a mac (sorry, wrong >newsgroup & too early in the morning). > >Thanks in advance, > >Dave Rotheroe {allegra, ihnp4, uiucdcs, ctvax}!convex!rotheroe >CONVEX Computer Corporation >Richardson, TX FinalWord II, by Mark of the Unicorn, should fit the bill. It's a complete word processing system that comes in two parts, an emacs like fully reconfigurable editor that sports an excellent macro programming language (even supports recursion!) and user definable menus/keystrokes, and a Scribe like formatter that on an Apple LaserWriter produces the best output I've seen this side of TeX. The size of the files the editor can handle is limited only by the size of its swap file; minimum size is circa 32K, maximum is 510K, the size can be changed by the user at any time and multiple users may have multiple swap files (they are searched for in you PATH if not found in the current subdirectory). Because of some internal overhead, the max file size to edit will be somewhat less than 510K even in the best case, but it should certainly fill your needs. In addition, the editor supports up to 6 windows, 23 files open at a time, lets you use either a direct write to the screen, BIOS, or Ansi.sys screen driver, does horizontal scrolling, has a maximum line lenght of about 32,000 characters (!), and stores in pure ASCII (although an option exists to use chr(255) as the newline character, it can and should be immediately turned off). Mail me if you need more info. Standard disclaimer applies: I have no connection with Mark of the Unicorn except as a satisfied user. - Tony catone@dsl.cis.upenn.edu catone@wharton.upenn.edu
catone@dsl.cis.upenn.edu.UUCP (04/08/87)
In article <246@uvicctr.UUCP> sbanner1@uvicctr.UUCP (S. John Banner) writes: > >Note: the VI from the MKS toolbox is the ONLY PC editor that I have >encountered that will edit a file that won't fit in memory (all at >once I mean). I have encountered several versions of VI for the PC, >and quite a number of other editors that I like, but this is the only >one that will do the disk buffering. > > S. John Banner > >UUCP ...!{uw-beaver,ubc-vision}!uvicctr!sol!sbanner1 >BITNET ccsjb@uvvm >ARPA sbanner1@sol.UVIC.CDN As I noted in a previous posting, FinalWord II by Mark of the Unicorn uses a swap file and does disk buffering. This also helps it recover editing changes in case your maching crashes (the swapping delay factor is user configurable). The original version of FinalWord also used this same system. - Tony catone@dsl.cis.upenn.edu catone@wharton.upenn.edu
billb@amcad.UUCP (04/08/87)
in article <119200008@convexs>, rotheroe@convexs.UUCP says: > Nf-ID: #N:convexs:119200008:000:726 > Nf-From: convexs.UUCP!rotheroe Apr 2 07:41:00 1987 > > > I know it was discussed recently, but I didn't pay attention then, and > can't find anything in the last ~150 notes now. > > Anyone have or know of a text editor which can edit 100-500k (usually ~150k) > ascii files. IBM's writing assistant and PC-write both seem to have a 64k > limit on file size - ugh - maybe I should have bought a mac (sorry, wrong > newsgroup & too early in the morning). > With MicroEMACS, a *very* good editor, the amount of RAM in your machine determines the size of the file you can edit. The whole file is loaded into memory. Best of all, it's public domain! If you have the capability to download files from a bulletin board system, you may be able get it at one in your area, otherwise, if you can't get it from anyone else, send me a disk and a SASE to mail it back to you, and I'll make you a copy. Bill USPS: William Burton P.O. Box 621 Concord, MA 01742 UUCP: ...seismo!husc6!amcad!billb
root@hobbes.UUCP (John Plocher) (04/09/87)
+---- Morris Jones writes the following in article <350@micropro.UUCP> ---- | +---- In article <103@hobbes.UUCP> I wrote | | I hate to drag up a program better left dead, but I've used WordStar 3.3 to | +---- | Any of the WordStar versions will handle file sizes limited by disk space | only. +---- NO!!!! - Every version of WordStar before 3.3 was limited to 8 Meg filesize. Even under MP/M which allowed 32Meg drives. Even under CCP/M which allows 500Meg drives. Even the ones for MS-DOS. Version 3.xx (where 1 < xx < 3, I forget which) went so far as to *silently* truncate files to 8 Meg! Versions before 3.x would not edit files larger than 8 Meg. I know - we've been using WS as our editor-of-choice on a CompuPro MP/M / CCP/M box for the last 6 years! We have 320 Meg of disk space (and *use* it!). That is why I put in the version number - older versions DIDN'T WORK RIGHT. Not a bad problem - I'd assume we were one of the FEW users who actually hit the 8 Meg boundry! But it needs to be pointed out that there WAS a limit. (This is NOT a flame!) +---- | Here's a little known tip: | ... Morris Jones, MicroPro Int'l Corp., Product Development +---- Thanks! -- John Plocher UUCP: <backbone>!uwvax!uwmacc!hobbes!plocher ============== Internet: plocher%hobbes.UUCP@uwvax.WISC.EDU FidoNet: 121/0 BITNET: uwvax!uwmacc!hobbes!plocher@psuvax1
James_R_Celoni@cup.portal.com.UUCP (04/10/87)
If you want to edit big files (to 500k, you said usually 150k), Mark of the
Unicorn/FW Corp.'s FinalWord II does it (to 512k) and plenty more. Check
reviews in Jan 86 PC mag (2 issues) and Apr 86 InfoWorld. +j
Celoni@score.stanford.edu
{decwrl!hplabs}!score.stanford.edu!celoniddb@viper.UUCP (04/15/87)
In the discussion of text editors on ms-dos for large files, I haven't
yet seen mention of Epsilong (from Lugaru Software, 5740 Darlington Rd,
Pittsburgh, pa 15217 (412)421-5911). It will edit files as big as I've
ever seen (over 500k) given space for swap file. It's also an emacs
look-alike in command set, and is completely rebindable and programmable
(using a c-like rather than a lisp-like internal language). It's also the
fastest ms-dos editor I've ever seen (considerably faster than Brief,
for example). They also provide the source code for most of the commands,
which can lead to considerable fun if you want.
--
David Dyer-Bennet
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!ddb
UUCP: ...ihnp4!umn-cs!starfire!ddb
Fido: sysop of fido 14/341, (612) 721-8967ddb@viper.UUCP (04/15/87)
I see that in my previous posting, in which I recommended the Epsilon text
editor from Lugaru Software, I typoed the editor name as "Epsilong".
Really, it's only about 150k, it's not THAT long! Anyway, the name of the
editor from Lugaru that I was recommending is Epsilon. Sorry for the
error.
--
David Dyer-Bennet
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!ddb
UUCP: ...ihnp4!umn-cs!starfire!ddb
Fido: sysop of fido 14/341, (612) 721-8967catone@dsl.cis.upenn.edu (Tony Catone) (04/20/87)
In article <846@viper.UUCP> ddb@viper.UUCP (David Dyer-Bennet) writes: >In the discussion of text editors on ms-dos for large files, I haven't >yet seen mention of Epsilong (from Lugaru Software, 5740 Darlington Rd, >Pittsburgh, pa 15217 (412)421-5911). It will edit files as big as I've >ever seen (over 500k) given space for swap file. It's also an emacs >look-alike in command set, and is completely rebindable and programmable >(using a c-like rather than a lisp-like internal language). It's also the >fastest ms-dos editor I've ever seen (considerably faster than Brief, >for example). They also provide the source code for most of the commands, >which can lead to considerable fun if you want. > >-- >David Dyer-Bennet Could you provide some timing tests for Epsilong? I'm curious, as I find FinalWord II by Mark of the Unicorn to be the fastest editor I've seen on micros, and am not sure that anything could be faster. If you post the findings for Epsilong, I'll do the same for FWII and any other editors we have around (MS Word, WordPerfect 4.1 and 4.2, MicroEmacs) that people might be curious about. I'd *love* to know which is the fastest editor around, since I spend so much time using mine. Tony Catone catone@dsl.cis.upenn.edu catone@wharton.upenn.edu
ark@alice.UUCP (04/20/87)
The fastest MS-DOS editor I've ever seen is DVED, from Robert Dewar. It is of somewhat unusual design, as it is really a sequential editor that tries very hard to hide the fact. In other words, there is an input file and an output file. Lines from the input file flow into the bottom of the screen; lines from the top flow into the output file. You can change anything on the screen. If you ask it to edit a single file, it puts the output in a temporary. On exit it renames the input file to the form *.BAK and renames the output file to replace the input file. If you try to back off the top of the screen, lines pushed off the bottom go into a temporary file. This file, if non-empty, is read in preference to the input file when taking new lines into the screen. This behavior has several interesting consequences: The size of a file is never limited by memory capacity. If you never back up more than a screenful, the editor doesn't use any more disk space than needed to contain the two copies of your file you'll want to keep anyway. If you do back up, it still doesn't use more disk space than it absolutely needs. If you jump from here to there in a file, you get there by traversing all the intervening text. This last characteristic might seem annoying, and indeed it would be if the editor weren't so incredibly fast. On a 4.77 mHz 8088, it manages about five screens a second (!). It's even faster on faster machines. Thus it is entirely comfortable to edit files with thousands of lines. Another interesting thing about DVED is its price -- it's free. Dewar wants people to re-distribute it (but not sell it) because it contains advertising for some of his other products. The advertising is completely unobtrusive -- you only see it if you ask for it explicitly in the help menu. The one disadvantage of DVED I have found it that it is WYSIYG (what you see is what you get) with a vengeance -- it won't let you produce a line that's too long to fit on the screen, period. In fact if you edit a file with lines longer than that, it will quietly truncate them. This deficiency is remedied in the version that he sells (for a pretty nominal price). Further information on request.
amir@booboo.UUCP (05/20/87)
In article <246@uvicctr.UUCP>, sbanner1@uvicctr.UUCP writes: > In article <119200008@convexs>, rotheroe@convexs.UUCP writes: > > > Anyone have or know of a text editor which can edit 100-500k (usually ~150k) > > ascii files. IBM's writing assistant and PC-write both seem to have a 64k > > limit on file size - ugh - maybe I should have bought a mac (sorry, wrong > > newsgroup & too early in the morning). > > The best one I have come across for that is the version of VI from the > MKS toolbox. This version is a very complete version of vi (I have seen > a few buggs, but the version I have is NOT the most recent)..... It's strange that you recommend this version of VI for this application. Have you ever run "chkdsk" after editing a file that is bigger than 32K bytes? If not, I recommend that you do that as soon as possible. The version that you have *will corrupt* your MS-DOS filesystem by creating duplicate clusters. Chkdsk can fix it but I sure as hell wouldn't trust this version. I caught this bug and reported it to MKS and they fixed it in the new version (which came out in January). This same version has a number of other bugs that could cause you to loose data. > .... Anyhow, it is FAST, complete, and > will edit just about anything (how often do you have to edit a file that > won't fit on your hard-drive twice...). > Now, the new version fixes the bug with large files but is SLOW. The screen update is about one line a second (in scroll mode)! God knows what made them slow it down. It still has bugs that can cause the system to crash (and erase your file) but you are hard pressed to find them. They could have a nice prodcut but given the state of their Korn shell (the thing is darn unusable -- it crashes your system every four or five commands!) and the vi, I hesitate to recommend this product to anyone. -- Amir H. Majidimehr Gould Inc, Computer Systems Division {sun,pur-ee,brl-bmd}!gould!amir
iadt3tb@gitpyr.gatech.EDU (T. Terrell Banks) (05/20/87)
In article <334@booboo.UUCP> amir@booboo.UUCP (Amir Majidimehr) writes: #In article <246@uvicctr.UUCP>, sbanner1@uvicctr.UUCP writes: #> In article <119200008@convexs>, rotheroe@convexs.UUCP writes: #> #> > Anyone have or know of a text editor which can edit 100-500k (usually ~150k) #> > ascii files. IBM's writing assistant and PC-write both seem to have a 64k #> > limit on file size - ugh - maybe I should have bought a mac (sorry, wrong #> > newsgroup & too early in the morning). #> #> The best one I have come across for that is the version of VI from the #> MKS toolbox. This version is a very complete version of vi (I have seen #> a few buggs, but the version I have is NOT the most recent)..... #It's strange that you recommend this version of VI for this application. #Have you ever run "chkdsk" after editing a file that is bigger than #32K bytes? If not, I recommend that you do that as soon as possible. #The version that you have *will corrupt* your MS-DOS filesystem by -------------- lines deleted ---------------- I'm using a text editor system from Command Technology Corp. called SPF-PC. It is a clone of the IBM SPF editor. The doc states " File size limited only by the capacity of the hard disk or extended/expanded RAM." I just edited a 225K file with no trouble. On an AT this editor is greased-lightening fast, it's just plain fast on slower machines. No trouble or bugs have been found to date and I recommend it highly. They advertise in most PC magazines. T. Terrell Banks Georgia Insitute of Technology Information Systems and Applications 190 Third Street NW Atlanta Georgia, 30332-0185 Internet: iadt3tb@pyr.gatech.edu uucp: ...!{akgua,ihnp4,hplabs,seismo}!gatech!gitpyr!iadt3tb Bitnet: iadt3tb@gitvm1
unicorn@pnet01.CTS.COM (Rich Herzog) (05/20/87)
I've had pretty good results on large files with Michael Ouye (SP?) 'SEE' editor, that seems to have come bundled with the DeSmet 'C' compiler package. It pages chunks in and out, so it's fast on the chunk you're working with. Works great if you're essentially sequentially operating on your large file.
davis@bdmrrr.bdm.com (Arthur Davis x4675) (05/22/87)
I use the Norton Editor from Peter Norton. It is RAM-based, but it will buffer the file to/from disk, and even informs you when this condition is present. It is a fairly simple editor and doesn't (thankfully) use WordStar command structure. Two windows are allowed, with straightforward cut and paste between them. It was written in IBM Macro-assembler and runs very quickly and I have never had reason to complain. The best thing is that it goes for $50.00 retail. It has some support for a mouse too, if you are into that. A nice escape to DOS feature lets you skip out to compile, link, and debug without leaving the editor, so to speak. I recommend it a lot around work, and everyone who has seen it has ended up using it and they seem to be pleased. Arthur Davis
keithe@tekgvs.TEK.COM (Keith Ericson) (05/23/87)
In article <334@booboo.UUCP> amir@booboo.UUCP (Amir Majidimehr) writes: [regarding the MKS vi, and later the MKS shell...] >Now, the new version fixes the bug with large files but is SLOW. The >screen update is about one line a second (in scroll mode)! God knows [OK - what *is* "scroll mode?" - kde] >what made them slow it down. It still has bugs that can cause the system >to crash (and erase your file) but you are hard pressed to find them. > >They could have a nice product but given the state of their Korn shell >(the thing is darn unusable -- it crashes your system every four or >five commands!) and the vi, I hesitate to recommend this product to >anyone. I cannot let this go by unchallenged. I have MKS Toolkit version 2.1 and I wouldn't give it up for the world. (Well, the WORLD?!?! OK, you can have my MKS Toolkit; it's a fair trade :-) ) The ONLY time I've had my system hang up is when I've tried to install something else strange on top of, or underneath, the MKS shell. Desqview has problems; sometimes my Ethernet access seems to get in the way (but so seldom that I can't pin it down on either, both, or an unfortunate interaction). OK, granted I'm not using vi as a program editor - I use it to write ms scripts, shell scripts, whatever I want to use it for. I've never had it crash on me. And I don't find it to be slow at ALL! I'm running it on a 286 ATClone and find it comparable to vi on our VAX-11/785+BSD4.3 system (even when rlogin'ed over a lightly loaded Ethernet). OK - timings, you want timings: here - the file being edited is approximately 577kbytes (the on-line company 'phone book). do ~6800 Load File replacements VAX-11/785+BSD4.3: 12 sec 15 sec 8MHz 286AT Clone: 22 sec 65 sec (with lots of disk access) Next test (suggested by complaint of screen scrolling speed): Go to top of screen; hit the 'k' key 10 times: screen finishes scrolling in 3 seconds (not 10!). I'm running from a Maxtor 2190 (via V-Feature Deluxe from Golden Bow systems) with a 3:1 interleave so my disk access times may not match yours. I've seen faster access times (a Seagate ST4038 with an interleave of 2:1) and slower (Seagate ST-225 20 Meg Half-height). No, I never saw any broken clusters by running chkdsk; and remember my test file was well over half-megabyte in size, 14467 lines! "Shift-G" and "1 Shift-G" went from one end of the file to the other *INSTANTANEOUSLY*. (How do they _do_ that?) Like I said: I _like_ the MKS Toolkit. I think you will, too, if you give it a try. keith (just a satisfied customer) ericson
kotlas@ecsvax.UUCP (Carolyn Kotlas) (05/24/87)
I also use the Norton Editor for general editing, short notes, etc. It's so simple to use that anyone can master most of the commands in 5 minutes. The only problem I've encountered is that it won't run on a Zenith 171 portable computer, although I've not had any problems with in on other Zenith models. -- Carolyn Kotlas (kotlas@ecsvax) UNC-Educational Computing Service P. O. Box 12035 2 Davis Drive Research Triangle Park, NC 27709 State Courier #315 919/549-0671
mrw@homxb.UUCP (05/25/87)
(Take this, line eater!)
I have had good luck editing gigantic files with but one editor:
The Personal Editor (PE) from IBM. It used to cost ~$60 or so, and
I hear the new version has windows. It puts as much of the file you're
editing into RAM, then commences doing disk swaps on the rest. I do
know that if you attempt a global change on the entire file, it may take
a while: however, it scrolls along right well, and searches aren't too
sluggish. You can configure the keys to do whatever commands you like.
It's basically you're staight ASCII editor. I wrote my thesis on the sucker.
It was MUCH better than xedit under a CMS system.
Ken Becker hotlv!kab
The opinions expressed above are my own, and not those of any company I
may work for. I am not associated with IBM, except as a happy customer
of the above product.mhnadel@gryphon.UUCP (05/28/87)
In article <3610@gitpyr.gatech.EDU>, iadt3tb@gitpyr.gatech.EDU (T. Terrell Banks) writes: > I'm using a text editor system from Command Technology Corp. called > SPF-PC. It is a clone of the IBM SPF editor. The doc states > " File size limited only by the capacity of the hard disk or > extended/expanded RAM." > I just edited a 225K file with no trouble. On an AT this editor is > greased-lightening fast, it's just plain fast on slower machines. No > trouble or bugs have been found to date and I recommend it highly. I use spf-pc a lot and generally like it but there are two limitations I've found (note that these aren't bugs since they're true of the mainframe version of spf as well.) One is that it cannot be used at all with files that have record lengths greater than 255. If you try it will just say that "record length exceeds spf-pc maximum." The other limitation is that there is no word entity. That is, you always have to delete either individual characters or lines and you can only move the cursor by characters or lines (or pages.) The lack of a tab character is also inconvenient for FORTRAN programming. On the other hand, it remembers the last settings you used (for disk, path and file extension as well as max record size and a bunch of other parameters) which can be very convenient and the multiple editing windows work nicely. I would probably recommend it primarily to people who are already familiar with SPF (i.e. those of us who suffer with TSO) and are willing to tolerate a few minor conveniences of other editors for the speed and familiarity. You might also note that there are at least two versions of spf-pc out there which seem to have minor differences between them. In bothe cases, the documentation is inadequate for those who have never used spf. Does anyone make a pc version of edt? Miriam Nadel -- "In a long dispute both parties are wrong." - Voltaire INTERNET: mhnadel@gryphon.CTS.COM UUCP: {akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!mhnadel UUCP: {philabs, trwrb}!cadovax!gryphon!mhnadel
iadt3tb@gitpyr.UUCP (05/28/87)
In article <555@gryphon.CTS.COM> mhnadel@gryphon.CTS.COM (Miriam Nadel) writes: >In article <3610@gitpyr.gatech.EDU>, iadt3tb@gitpyr.gatech.EDU (T. Terrell Banks) writes: >> I'm using a text editor system from Command Technology Corp. called >> SPF-PC. It is a clone of the IBM SPF editor. The doc states > >I use spf-pc a lot and generally like it but there are two limitations >I've found (note that these aren't bugs since they're true of the mainframe >version of spf as well.) One is that it cannot be used at all with >files that have record lengths greater than 255. If you try it will >just say that "record length exceeds spf-pc maximum." The other limitation >is that there is no word entity. That is, you always have to delete either SPF-PC Version 1.82 (what you get if you buy it today -- or at least 5 weeks ago) will edit files with records up to 955 characters in length, that may be 954 but at any rate it's in the 950 range. The older versions may not have been able to do this. I've not tried this yet, this is just what is on the edit entry screen where you specify the file name. You are so very right about the "word entity", it would be really handy to have this. Cheers, Terry Banks Georgia Insitute of Technology Information Systems and Applications 190 Third Street NW Atlanta Georgia, 30332-0185 Internet: iadt3tb@pyr.gatech.edu uucp: ...!{akgua,ihnp4,hplabs,seismo}!gatech!gitpyr!iadt3tb Bitnet: iadt3tb@gitvm1
2212msr@whuts.UUCP (06/01/87)
> > I use spf-pc a lot and generally like it but there are two limitations > I've found (note that these aren't bugs since they're true of the mainframe > version of spf as well.) One is that it cannot be used at all with > files that have record lengths greater than 255. If you try it will > just say that "record length exceeds spf-pc maximum." The other limitation > is that there is no word entity. That is, you always have to delete either > individual characters or lines and you can only move the cursor by characters > or lines (or pages.) > The lack of a tab character is also inconvenient for FORTRAN programming. > > Miriam Nadel I belive that Miriam is using an old version of SPF (>2 years old). SPF/PC, Release 1.82 allows record lengths of 954 characters. This release has been out for well over a year. On her other comments I agree. Max S. Robin AT&T Bell Laboratories Whippany, NJ email:whuts!2212msr voice:201-386-6865 .
amir@booboo.UUCP (06/02/87)
In article <2311@tekgvs.TEK.COM>, keithe@tekgvs.TEK.COM (Keith Ericson) writes: > [regarding the MKS vi, and later the MKS shell...] > > >Now, the new version fixes the bug with large files but is SLOW. The > >screen update is about one line a second (in scroll mode)! God knows > > [OK - what *is* "scroll mode?" - kde] Sorry for the lousy terminology. I meant using ^Y and ^E to scroll lines up and down. > > >what made them slow it down. It still has bugs that can cause the system > >to crash (and erase your file) but you are hard pressed to find them. > > > >They could have a nice product but given the state of their Korn shell > >(the thing is darn unusable -- it crashes your system every four or > >five commands!) and the vi, I hesitate to recommend this product to > >anyone. > > I cannot let this go by unchallenged. I have MKS Toolkit version 2.1 ^^^^^^^ This is for all the people that think are responding to my posting: I have used version 1.X and 2.0 of this product. MKS has not notified me of anything newer. I only learned from you folks that there is a version 2.1 (thanks!). Therefore you may not see these problems in your version. But they are definitly in version 2.0. > OK, granted I'm not using vi as a program editor - I use it to write > ms scripts, shell scripts, whatever I want to use it for. I've never > had it crash on me. And I don't find it to be slow at ALL! I'm > running it on a 286 ATClone and find it comparable to vi on our > VAX-11/785+BSD4.3 system (even when rlogin'ed over a lightly loaded > Ethernet). The 1.X version was lightning fast. You could *never* see it update the screen. The new page would simply flash on the screen. The version 2.0 however, can not keep up with the repeat rate of my AT (8 MHZ) machine. I can't comment about the VAX 785 but my Unix box at work keeps up with the repeat rate of my Televideo keyboard through Ethernet at 9600 baud. Also, I am a heavy user of vi. I routinely edit files in excess of 1500 lines and 50K bytes. Reliability of the package and the speed are of utmost importance to me. > > OK - timings, you want timings: here - the file being edited is > approximately 577kbytes (the on-line company 'phone book). > > do ~6800 > Load File replacements > VAX-11/785+BSD4.3: 12 sec 15 sec > > 8MHz 286AT Clone: 22 sec 65 sec (with lots of > disk access) Wrong test. Nobody disbuted the speed of file loading or anything else for that matter. I probably use ^E and ^Y more than any other commands in vi and can't stand the slow *screen* update. > Next test (suggested by complaint of screen scrolling speed): > Go to top of screen; hit the 'k' key 10 times: screen > finishes scrolling in 3 seconds (not 10!). > There you are. I am not sure about the repeat rate of the AT keyboard but I think it is around 10 chars/sec. Using your numbers, the editor is scrolling three times slower that the repeat rate. Therefore you have to put up with the beeps from the machine as the input buffer fills up. Haven't you ever scrolled backwards through the file using ^Y? I hate to have to stop for the machine to catch up and then press the key again specially when the older version didn't have this problem. > No, I never saw any broken clusters by running chkdsk; and > remember my test file was well over half-megabyte in size, 14467 > lines! "Shift-G" and "1 Shift-G" went from one end of the file to > the other *INSTANTANEOUSLY*. (How do they _do_ that?) The problem was only in version 1.X. Since you are running 2.1 you wouldn't run into it. But I had to put up with it for three months. Imagin running chkdsk every hour on a 30 Meg disk and fixing duplicate clusters that point to your data in other areas of the disk. > > Like I said: I _like_ the MKS Toolkit. I think you will, too, if you > give it a try. > I have given the version that I have more than a try. I have used the package for about 8 months for about 4 hours a day. I like all the tools and put up with the bugs for that reason. I just think that it would be nice for the company to let me know when and if they fix these problems so that I am not left in the dark. Is that too much to ask??? -- Amir H. Majidimehr Gould Inc, Computer Systems Division {sun,pur-ee,brl-bmd}!gould!amir