mark@bruce.OZ (Mark Goodwin) (07/17/89)
Has anyone ported vi to Minix? I'm such a vi addict that there is no substitute. If no-one has, I'll see about porting the "stevie" vi clone posted to comp.sources.unix about 1 year ago (v15i037-042). -- Mark Goodwin, Programmer @ Monash Uni. Comp. Sci.
ast@cs.vu.nl (Andy Tanenbaum) (07/17/89)
In article <1385@bruce.OZ> mark@bruce.OZ (Mark Goodwin) writes: >Has anyone ported vi to Minix? I have stevie running on MINIX. It is pretty vi like, but keeps the file being edited in core, which limits it to files of around 50K. It really is not well polished. If you are really a vi addict, you could volunteer to finish it off :-) The source is 56 files and 375K bytes C text. That shouldn't deter a real vi addict. Emacs is 10 times that. I think the source should be in the archives. I am not wild about sending 375K to Australia, but will do it if you can't find it elsewhere. Andy Tanenbaum (ast@cs.vu.nl)
peter@ficc.uu.net (Peter da Silva) (07/18/89)
In article <2892@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > In article <1385@bruce.OZ> mark@bruce.OZ (Mark Goodwin) writes: > >Has anyone ported vi to Minix? > I have stevie running on MINIX.... If you are really a vi addict, you could > volunteer to finish it off :-) If anyone wants to do a *real* port of vi to MINIX, a good place to start would be the Software Tools version of 'ed'. After all, the real 'vi' got started with enhancements to the real 'ed'. If anyone wants, I have a version of Software Tools 'ed' in C somewhere, and I could probably dig it up. Converting it to 'vi' is one of those things I've never gotten around to... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "A char, a short int, and Personal: peter@sugar.hackercorp.com. `-_-' | an int bit-field were walking Quote: Have you hugged your wolf today? 'U` | through the forest..."
walker@hpl-opus.HP.COM (Rick Walker) (07/19/89)
> /hpl-opus:comp.os.minix/ast@cs.vu.nl (Andy Tanenbaum)/2:58 am Jul 17, 1989 / > In article <1385@bruce.OZ> mark@bruce.OZ (Mark Goodwin) writes: > >Has anyone ported vi to Minix? > I have stevie running on MINIX. It is pretty vi like, but keeps the file > being edited in core, which limits it to files of around 50K. It really > is not well polished. If you are really a vi addict, you could > volunteer to finish it off :-) The source is 56 files and 375K bytes C text. > That shouldn't deter a real vi addict. Emacs is 10 times that. I > think the source should be in the archives. I am not wild about sending > 375K to Australia, but will do it if you can't find it elsewhere. > > Andy Tanenbaum (ast@cs.vu.nl) > ---------- There is a very good vi clone, called 'S' written by Webb Miller and presented in his book "A Software Tools Sampler" published by Prentice Hall. Webb describes the implementation of S from the ground up and does a great job of writing well thought out, modular code that is easy to understand. I have a modified version of the code that was typed in by steve@cluster.cs.su.oz. Steve has modified the buffer routines to keep the text for a line in a temp file so that fairly large files can be handled. Only the pointers to the text information are kept in memory. Steve also added regular expression support to the search commands. Steve's version of S runs on MS-DOS, UNIX and CP/M. I have made a few modifications to bring the code into more faithful vi emulation, adding some of the more obscure addressing commands like '%'. It currently does a great job in visual mode. Gradually I have been adding in support for the ex mode commands. I have been trying hard to make all modifications with the same stylistic purity of the original code. The main difference between S and stevie is that S was originally a well-polished modular piece of code, written for publication and critical perusal - whereas stevie has more or less evolved to its present condition. For instance, the version of stevie that I have has the undo command in a state of disrepair, but S has clean support for the undo function transparently built into the buffer manager code. I have been working on rewriting the lowest buffer primitives to keep everything about the work file in a scratch file. There was a good description of such "virtual memory" buffer routines in: "Red, a better C screen editor", Dr. Dobbs Journal, Number 81, July 1983, pg 361-379. After this modification (which should be fairly painless, due to the modular nature of the code), S should be able to edit files as big as the disk free space. S should easily transport to any UNIX system which supports termcap routines (Otherwise you have to resort to hard-coding the terminal escape sequences). If S fits on CP/M it should easily fit on MINIX. The most interesting question is whether Webb Miller and Prentice Hall can be convinced to allow S to be distributed with MINIX or on the net. I believe that wide publication of S would certainly help sell more of Webb Miller's great book (I bought it). If permission could be obtained, I could post the current version or make it available to interested parties. ------------- -Rick Walker ...!hplabs!walker
jac@paul.rutgers.edu (Jonathan A. Chandross) (07/19/89)
peter@ficc.uu.net (Peter da Silva) > If anyone wants to do a *real* port of vi to MINIX, a good place to start > would be the Software Tools version of 'ed'. After all, the real 'vi' got > started with enhancements to the real 'ed'. Actually, Bill Joy (and Mark Horton, I think) started out using ed, but soon abandoned it when it became clear that it wouldn't work. They wrote ex instead, and put vi on top of it. This is, reportedly, no ed code left in vi/ex. Jonathan A. Chandross Internet: jac@paul.rutgers.edu UUCP: rutgers!paul.rutgers.edu!jac
ast@cs.vu.nl (Andy Tanenbaum) (07/19/89)
In article <62840001@hpl-opus.HP.COM> walker@hpl-opus.HP.COM (Rick Walker) writes: >There is a very good vi clone, called 'S' written by Webb Miller and >presented in his book "A Software Tools Sampler" published by Prentice >Hall. >The most interesting question is whether Webb Miller and Prentice Hall >can be convinced to allow S to be distributed with MINIX or on the net. I think that if you or someone else can port S to MINIX and make it robust, that P-H would probably either (1) sell it as a separate product or (2) allow me to include it with MINIX. The remaining possibility (suppressing it) is not likely, especially if they can sell it one way or another. If it is really good and the price is not unreasonable, they might sell a fair number. Andy Tanenbaum (ast@cs.vu.nl)
peter@ficc.uu.net (Peter da Silva) (07/19/89)
In article <Jul.18.22.24.39.1989.29326@paul.rutgers.edu>, jac@paul.rutgers.edu (Jonathan A. Chandross) writes: > peter@ficc.uu.net (Peter da Silva) > > If anyone wants to do a *real* port of vi to MINIX, a good place to start > > would be the Software Tools version of 'ed'. After all, the real 'vi' got > > started with enhancements to the real 'ed'. > Actually, Bill Joy (and Mark Horton, I think) started out using ed, but > soon abandoned it when it became clear that it wouldn't work. They wrote > ex instead, and put vi on top of it. This is, reportedly, no ed code left > in vi/ex. This really doesn't effect the desirability of starting with the Software Tools 'ed', though. (a) There's no UNIX 'ed' code in there, and there's no relationship between the internals, so whatever internal problems existed in UNIX 'ed' aren't relevant. (b) These days the Software Tools 'ed' looks more like 'ex' anyway... you know, readable error messages and stuff. The basic thing here is that unless you start with something that looks like 'ed' or 'ex' you're going to either have to add it in later (to fully support vi's EX mode and : commands), or give up on full 'vi' compatibility. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "A char, a short int, and Personal: peter@sugar.hackercorp.com. `-_-' | an int bit-field were walking Quote: Have you hugged your wolf today? 'U` | through the forest..."
williamo@hpcupt1.HP.COM (William O'Shaughnessy) (07/19/89)
Stevie, the vi clone that runs on minix, unix, and the ST, can edit files as large as the system can malloc. I hope minix can malloc more that 50K. I have edited 4 million byte files with stevie on the MPE/XL operating system. It's performance was quite respectable. Even on an IBM PC it can edit 300K byte files. Bill O'Shaughnessy The above opinions are my own and may not be those of my employer. No warranties are implied or given.
dtynan@altos86.Altos.COM (Dermot Tynan) (07/20/89)
In article <Jul.18.22.24.39.1989.29326@paul.rutgers.edu>, jac@paul.rutgers.edu (Jonathan A. Chandross) writes: > > Actually, Bill Joy (and Mark Horton, I think) started out using ed, but > soon abandoned it when it became clear that it wouldn't work. They wrote > ex instead, and put vi on top of it. This is, reportedly, no ed code left > in vi/ex. > > Jonathan A. Chandross I don't think this is true. Berkeley is very good about releasing code which is free of AT&T source. Case in point: Mail. Bill Joy used 'ed' to develop 'ex' (which later became 'vi'), and used the bourne shell (/bin/sh) to develop his C-shell. Because of this, neither product is available from Berkeley, without a source licence. Having looked at both shells, there doesn't seem to be much correlation, but then I'm not an Attorney :) - Der -- dtynan@altos86.Altos.COM (408) 946-6700 x4237 Dermot Tynan, Altos Computer Systems, San Jose, CA 95134 "Far and few, far and few, are the lands where the Jumblies live..."
mark@bruce.OZ (Mark Goodwin) (07/20/89)
From article by walker@hpl-opus.HP.COM (Rick Walker): > The main difference between S and stevie is that S was originally a > well-polished modular piece of code, written for publication and > critical perusal - whereas stevie has more or less evolved to its present > condition. For instance, the version of stevie that I have has the undo > command in a state of disrepair, but S has clean support for the undo > function transparently built into the buffer manager code. > Sounds like `s' is a much better place to start than `stevie' - clean code to begin with must certainly result in a better final product. And to edit arbitrarily large files efficiently is a must. > The most interesting question is whether Webb Miller and Prentice Hall > can be convinced to allow S to be distributed with MINIX or on the net. > I believe that wide publication of S would certainly help sell more of > Webb Miller's great book (I bought it). If permission could be obtained, > I could post the current version or make it available to interested parties. Please post the current version if permission can be obtained from Webb Miller. Does permission from PH really matter? If the current version is incomplete, I volunteer to clean it up (if no one else wants to). Many thanks -- Mark Goodwin, Programmer @ Monash Uni. Comp. Sci.