Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!rutgers!lll-crg!nike!ucbcad!ucbvax!decvax!decwrl!sun!guy
From: guy@sun.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Editor macro languages
Message-ID: <8293@sun.uucp>
Date: Sat, 18-Oct-86 02:38:59 EDT
Article-I.D.: sun.8293
Posted: Sat Oct 18 02:38:59 1986
Date-Received: Tue, 21-Oct-86 20:53:45 EDT
References: <4508@brl-smoke.ARPA> <798@mtund.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 50

> Being able to use the shell, or a programming language of one's
> choice, instead of having to learn a custom editor macro language,
> is one of the tremendous advantages of working under Unix. I once
> implemented a syntax-directed editor as a set of vi macros filtering
> text through a few shell scripts and one C program, in a quarter of the
> time it would have taken to write an SDE from scratch. When a novice
> complains that some part of Unix is not powerful enough, the cure
> is RTFM.

Yeah, but what if they're, impossible though it may seem, *right*?  Reading
the manual won't help....

Yes, there are lots of wonderful things you can do with pipelines and
filters, blah blah blah.  However, it is not the case that you can do
*everything* with them.  Consider implementing an editor that performs some
complex function on every keystroke, such as the "text mode" in many EMACS
implementations.  It will do word wrapping as you type; it won't reformat
the paragraph as you type, so it's a nuisance to insert into a paragraph,
but it beats the h*ll out of having to type the newlines yourself when you
get near the end of a line.  I sincerely doubt you'll get anything near
acceptable performance if you run a filter every time you type a character.

As for *having* to learn a "custom" editor macro language, you don't *have*
to learn anything if you want to use EMACS.  It has a "filter-region"
command, that takes a marked region and runs it through a filter, so you
*can* do that sort of thing when it's appropriate.  The difference here is
that you don't have to when it *isn't* appropriate.  The fair comparison
here would *not* be between writing an SDE from scratch and using "vi"
macros, it would be between writing one using "vi" macros and writing one in
an EMACS extension language.

NOTE:  this was not intended as another boring "EMACS is better than 'vi'
because I'm used to EMACS and not used to 'vi'" (or *vice versa*)
content-free postings of the sort that have been cluttering the net
recently.  I have my own opinion on the subject, and it's as worthless as
everybody else's opinion; EMACS is better for *me*, but that doesn't in any
way indicate whether it's better for anyone else.  If you are more
productive using "vi" than using EMACS, and somebody tells you "no, you'd be
better off using EMACS because it's modeless" or "because it has an
extension language" or whatever, they're full of it.

It is, instead, pointing out that while certain problems can be solved
elegantly by gluing UNIX tools together, other problems are better solved
using different techniques.  Some of UNIX's more ardent admirers tend to
dismiss useful ideas that don't fit into their idea of "the UNIX way of
doing things", and this is a serious mistake.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)