Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpl-opus!walker
From: walker@hpl-opus.HP.COM (Rick Walker)
Newsgroups: comp.os.minix
Subject: Re: vi under minix
Message-ID: <62840001@hpl-opus.HP.COM>
Date: 19 Jul 89 01:03:33 GMT
References: <1385@bruce.OZ>
Organization: HP Labs, High Speed Electronics Dept., Palo Alto, CA
Lines: 61

> /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