Xref: utzoo comp.editors:2784 comp.unix.misc:1169
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!bloom-beacon!eru!hagbard!sunic!mcsun!cernvax!chx400!chx400!bernina!neptune!inf.ethz.ch!wyle
From: wyle@inf.ethz.ch (Mitchell Wyle)
Newsgroups: comp.editors,comp.unix.misc
Subject: Re: If you could have anything in vi ...
Summary: get vi "right" first, then add features
Keywords: get it right!
Message-ID: <27673@neptune.inf.ethz.ch>
Date: 22 Mar 91 10:39:07 GMT
References: <1991Mar18.195343.665@cs.widener.edu> <7214@ecs.soton.ac.uk> <7220@ecs.soton.ac.uk> <1991Mar21.065353.1341@cs.ucla.edu>
Sender: news@neptune.inf.ethz.ch
Reply-To: wyle@inf.ethz.ch (Mitchell Wyle)
Organization: Departement Informatik, ETH, Zurich
Lines: 65

In <1991Mar21.065353.1341@cs.ucla.edu> 
gast@maui.cs.ucla.edu (David Gast) fantasizes:

>>>> So .. what would you have added to vi, if you could? What would you
>>>>have made an option? What would you change?

>I hope you mean a program like fmt, not one like nroff.  

what about something like curses-perl where you link (perhaps dynamically)
pieces of your own (or Berkeley's or someone else's) code into the editor,
making it object code extensible instead of lisp-interpreter extensible?

...not that I'd use it; it's just a thought.

>Anyway, since fmt is freely available, I would just package it
>with your program and leave it out of the editor.

Nope; those of us who type over 100 wpm do not want to wait for {!}fmt^V^M
to come back, even when it takes just a few hundred milliseconds.  We
want a wordstar-like ^B command built-in.  This wish is #2 on my list.
Sorry, fmt has to be a built-in. :-}

>>>2) A more flexible way of editing several files and transferring
>>>   between them. 
>
>More than one window on a file would be nice too.

I've gotten used to vi the way it is; this one is not important to me.
People coming from other editors want it; I guess it's important in
general.

>Here are some more ideas.  In some cases, I recognize that they can be
>done now, but in an inconvenient manner.
>
>1. All bugs fixed.

I'm glad Dave has his priorities straight.  I'll add:

0.  Consistent or compatible with REAL UNIX vi.

I complained three times to elvis author Steve Kirkendall
(kirkenda@cs.pdx.edu) that elvis suffered from creeping featurism and was
not consistent with Sun-OS vi, or any of the other Unix vi's I use.  Elvis
1.4 does not interpret map macros correctly, dumps core on Sun-0S, and has
enough inconsistencies for me not to use it on Unix (I use it on DOS).

So:  think big but start small.

Make it stable, consistent and compatible with BSD vi, then add features.
Don't let the neato features take all your time from fixing bugs or add
some feature which makes your vi completely incompatible with the real vi.
Steve's :cc command is good.  The inability to let elvis wrap (forced 
sideways scrolling) is bad.  I actually am getting to like the sideways
scrolling, but I want a vi clone to be at least COMPATIBLE with the 
real vi.  One should be able to turn features off when they conflict with
BSD vi's methods, bugs, features, weirdisms.

>5. Display lines of arbitrary length.

emacs users can emacs executables and change hard-coded paths and other
areas.  I wish vi could do that...

>David Gast

Mitch Wyle