fostel (04/14/83)
I used, and enjoyed the Rand Editor for a number of years, and have also
used extensively, a variety of other editors, including vi, emacs, sed
and have learned one thing: >>50% of the users of an editor will defend
"their" editor which they know very well, as clearly superior to the
clearly mis-guided strategies of the other editors they don't know very
well at all. Any editor which survies longer than a year or two clearly
has something going for it. Sadly the UNIX/vi community is at least as
close-minded about these things as the rest of the world. Some will even
make pronouncements about sending the discussions to bit buckets as clearly
worthless mumbling.
" ... its treatments of tabs is a feature, not a bug ..."
I submit that few unix/vi hackers are capable of understanding that comment
because it relates to a "style" of editing which is simply different from
the usual UNIX hacker model. (I use hacker with a variety of connotations
ranging from reverence to insult.) Individual facets of a complex idea often
look quite silly out of the proper context. Perhaps that style is better,
perhaps it is not. For myself, when I had access to both vi and the RandEd,
I used each, in turn, depending on the needs of my editing tasks. The
RandEd seems (to me) to be quite nicer for initial typing, formating, and
reading/scanning files. Its screen refresh strategy causes somewhat less
eye-strain then vi. The unification of insert and command mode eliminates
the many mistakes I often make forgeting which mode I'm in. (at a cost of a
small command set). The Rand Ed window capability makes Vi's multiple file
editing look a bit sick. Vi is quite clearly superior in logical capability
and I tended to use it for complex, sweeping "1,$s ..." changes. (Though
for anything truely tricky, I used a UNIX teco out of habit.)
The notion of a tab character is NOT a universally revered one. A program
called "untab" used to be one of my favorites. I happen to think that disk
space was made to be used and the ~20% space penalty for blanks is quite
acceptable to me. (For source ONLY! English text has effectively 0 penalty)
Vi's habit of not letting me go to some places on the
screen, or failing to match a " " on a search was occasionally NOT accept-
able. (I fully expect to be told to use the uppercaseshiftmetalcntl
S command to avoid this. Indeed the proliferation of commands in Vi has
always struck me as antithetical to the "UNIX Concept", and closer to the
EMACS Hacker concept.)
Some "features" of the RandEd were lamentable -- and their number was quite
substantially reduced by any serious effort to clean up the code. Dave
Taenzer at BBN produced one such clean version, later perverted into a BBN
product called Pen. Mitre Labs also did a very nice clean up job. As did
a UNIX vendor with such sleazy Salespeople I refuse to give them a plug
by mentioing them by name. I suspect that many negative experiences with
the RandEd would be reversed by exposure to a de-bugged copy.
I would not recommend any serious new project to "clean it up" again. The
code quality does tend to be spurious in places: It is a very old program
which has suffered many abuses over the years. It was written initially as
a "lets learn C" program and grew from there. It will probably be easier to
rewite it then maintain it into a good state. TOO MUCH criticism of the code
and documentation seems inappropriate in UNIX land, where poor code and
inexcusable documentation are quite the rule, not the exception.
----GaryFostel----mjl (04/16/83)
Ok, since the vi/rand debate seems to be of monumental importance, I'll put in my two cents. Actually, I'll home in on the one point that seems to have caused the most controversy--tab replacement by spaces. I've used a variety of editors in the 15 years I've been in the business, from Basic line number editors to TECO to a piece of junk on the CDC NOS system to 'ed' to SDS/XDS/Honeywell Sigma 9 EDIT to the rand editor to vi (just to establish my credentials). I have always liked editors that keep "tabs as tabs" better than those that replace tabs with spaces. NOT because of the space saved; I agree that's a red herring. Rather, tabs are an extraordinarly useful delimiter when searching for and lining up columnar data (including source statements). When I have to rearrange text, especially text whose indentation reflects its structure, tabs are much easier to work with than a pseudo-random collection of spaces. Keep the two concepts distinct; they serve distinct purposes. And if you don't want tabs, filter your file through expand(1). Mike Lutz allegra!rochester!ritcv!mjl