Broff and a proposed net project

[guy at rlgvax.UUCP]

	Wang has, therefore, done well with an editor that shows you pretty
	much what you would see on paper. But you pay a price: The text files
	contain formatting information, so they can't be easily viewed without
	the text processor; On most Unix systems, mimicing the Wang display
	style would mean transmitting a dozen or more characters for each
	character typed! Yow, Vaxen eaten alive by ravenous DZs! Of course
	this matters less, if at all, on personal workstation machines.

Yes, our system does require you to use either the word processing editor or
print program to view a document.  This isn't too much of a hardship.  (Also,
any ordinary UNIX text file can be used with the word processor, but the NL
at the end of every line is treated as a hard return.)  We used to display
a column counter as you typed, but don't anymore, to cut down on that trans-
mission overhead (also, we use DHs, not DZs, for our users).

	But, if you strip off some of the features, you can build a good
	mixed-mode text processing system that does most things as you type,
	and time consuming things later. A recent Seybold Report had good
	things to say about one Wangish text processor by NBI, but it requires
	hardware support (for the IBM PC), and one mixed-mode system, by Mark
	of the Unicorn. (And if you think that's an odd name, NBI stands for
	Nothing But Initials.) And Wang has their own re-implementation of
	their text processor running on their PC.

The reason the NBI (which originally stood for something *really wierd* until
the inventor of the name left NBI and took the rights to the name with him;
they then retroactively changed it to Nothing But Initials) word processor
requires hardware support is that the NBI 3000 uses a Motorola 6800, the
software is written in assembly language, and they figured it was easier and
quicker to put in a 6800 card rather than rewriting it in 808* assembler or
a high-level language.  Microsoft has a editor/formatter for the PC (Multi-Tool
Word) which uses the bitmap to display characters; it may be slow, but if you
wanted to use the character generator you could do a full editor/formatter
without any special hardware.

	If you say emacs is expensive, you better say which one.

The EMACS I was told was a hog was one of the common UNIX EMACSs, probably
not MINCE (and the reason it's not as fast as MINCE is probably that it
does support MockLisp.)

	But back to "Unix meets Wangwriter." Another reason Wang-like text
	processing does not fit in well with Unix is that almost every file that
	contains data on Unix is human readable. So unless you opt for complete
	integratation -- like in the Lisa or Star -- awk , sed, diction, spell
	and etc. are going to have as hard a time dealing with your bussiness
	letters as you would without the editor.

A simple solution, which we have adopted (although we haven't made the program
an "official" part of the system yet), is to have the moral equivalent of
"deroff" (yes, "nroff" sometimes suffers from the same problem) which works
on our word processor's document.  When you say UNIX, by the way, perhaps you
should say "the UNIX text processing utilities".  A UNIX system being used
for laboratory instrument control may not spend very much of its time piping
text processing utilities together....  And we *did* opt for such integration
("awk" isn't too happy working on free text anyway, as it's really oriented
towards records with fields); we have a spelling checker based on Proximity
Devices' lexicon and code that *INTERACTIVELY* scans through the document,
finds words not in the lexicon (it's not a hashed spelling checker, so the only
way you get a false hit or miss is if the lexicon itself is bad), and when it
encounters one it stops, highlights the word FROM WITHIN THE EDITOR, and
permits you to correct it interactively.  You can even see a selection from
the lexicon if you aren't sure of the correct spelling.  MUCH nicer than running
a batch program, getting a list of words not in the dictionary, and having to
go through the document and find and correct them yourself.  I have run our
documents through "diction" (and found it to be a bigger pain in the *ss than
"lint", in terms of complaining about things that you really can't fix) and
"style", using our "deroff"-style program.  Next to NO work needed to be done
to do that, once the program was written; just tweak the "style" shell file
slightly.

The statement that "Wang-style text processing doesn't fit in well with UNIX"
is simply false.  I don't like to see certain applications deemed "unfit for
UNIX" because they don't fit the common model of text processing filters
piped together.  UNIX is fit to run any application that isn't grossly
inconvenient or inefficient to implement under it.  (Note that both Bell and
Berkeley have started working on putting IPC facilities - shared memory,
semaphores, message mechanisms - into UNIX, precisely because you can open up
UNIX's applicability greatly without doing violence to the system by adding
such facilities), regardless of whether it accesses text files sequentially
or not.)

I remember somebody claiming that Fortran didn't belong under UNIX
because programs written in Fortran didn't fit the "UNIX style".  What this
would mean in practice is "Well, you unwashed Fortran programmers don't
deserve to have a hierarchical directory structure to organize your files,
or UNIX's facilities to edit, compile, and debug your code, or... - sorry,
you'll have to use RSX-11M."  We used UNIX at Harvard College Observatory mostly
as a base for running scientific applications written in Fortran.  It is a LOT
more "user-friendly" than RSX-11M.  "What do you mean I don't just type ^C to
abort my program, I then have to type 'ABO' if I ran it with 'RUN' and
'ABO ...PIP' if I ran it with 'PIP'?  For that matter, what do you mean I
have to say 'PIP FILE2.FOR=FILE1.FOR' instead of 'cp file1.for file2.for'
(anybody who thinks "cp" is cryptic and doesn't suggest copying, while "PIP"
is clear and obviously suggests copying, raise your hands).

I just don't buy the notion that UNIX should be a narrowly targeted system.  If
that approach is taken, a small group of people will love it and the vast bulk
of the world will never bother with it.  And I especially don't think that the
model of building an application by joining filters together should be taken as
the way to do *everything*.  This model fits several applications very poorly,
and text editing/formatting (as opposed to the sort of text processing that
some of the Writer's Workbench software does) is one of them.  Given the choice
between the "conceptual cleanliness" of an editor and a formatter, and the
"user-friendliness" of getting immediate, rather than delayed, feedback, I'll
take the latter every time.  The technique of organizing an application as
filters is a tool like any other tool, to be used only when it is better than
other tools.  Don't use a saber saw to slice bread.

The Seybold Report, by the way, has a strong bias in favor of "what-you-see-
is-what-you-get" systems.  They even prefer to show margin justification on
the screen, which we and Syntrex do (Syntrex's Aquarius is another system done
by a bunch of UNIX hackers, by the way).  For that matter, another UNIX system
with a full editor/formatter is Fortune, with their Wang-clone, and another is
the new NBI 68010 workstation.  As I've said, the battle between editor/
formatters and separate editor/formatter combinations has already been fought
and won by the former; you're fighting a rear-guard action.  For complicated
layouts, the separate editor and formatter may still win, although it is not
inconceivable that faster hardware or cleverer designs may make an interactive
editor/formatter possible even for them.

	Guy Harris
	{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy