From: utzoo!decvax!cca!mark.umcp-cs@UDel-Relay@sri-unix
Newsgroups: net.unix-wizards
Title: Re: useful view extension
Article-I.D.: sri-unix.4362
Posted: Wed Nov 24 01:10:31 1982
Received: Thu Nov 25 12:14:31 1982

From:     Mark Weiser <mark.umcp-cs@UDel-Relay>
Date:     21 Nov 82 11:20:23 EST  (Sun)
"don't extend vi, do it yourself with a shell script:" -- that's
	sick.  I cannot believe that anyone with any talent at using
	a Unix system would write a shell script for something that
	they (or anyone else they give it to) will use often.  
It depends on how often and on the cost of rewriting in C versus
keeping the script.  There is some code that I may never find the
time to rewrite in C, because it involves a 10 process pipeline and runs
once a month (but is still 200 lines of script).  I can't believe anyone 
with any talent at using a Unix system would avoid the shell just because 
they plan to run the program more than once.
	Parsing arguments, handling interrupts, etc. are best done in a program,
	not a shell script.  
Not at all.  The shells are ideal for passing arguements, much
better than C for normal use.
	I think "vi" is large and complex, but it is clearly the place to
	put the additions.  How do you suspect "vi" reads in its input
	file into its buffer in the first place?  Would it be too much
	trouble to alter the mechanism which does that to accept
	standard input rather than opening a file?  I think not.
The problem with this approach is two fold.  First, if you are
the system manager then you have just introduced an extra level
of maintenance for yourself as future revisions of vi are
released, people migrate to your system who are used to the
unextended vi, etc.  Second, if multiple vi's are kept around,
there is a problem with occupying unnecessary disk space for
object files.  (Our two rp06's run at 99% or worse all the time,
so that is a serious problem here.)
	Then of course is the multi-pass nature of your approach: one pass
	to copy to /tmp/, one to read into "vi", and if you wanted to alter
	it, you'd also make another to copy from /tmp/ to standard output.
	Yuch again.
Hey, multiple passes are great!  Efficiency of programmer time is
much more important than efficiency of machine time.