Is there any wordprocessor in unix

[Bill Stewart 201-949-0705 ho95c.att.com!wcs]

In article <1143 at ssp15.idca.tds.philips.nl> jos at idca.tds.PHILIPS.nl (Jos Vos) writes:
= In article <228 at psgdc> rg at psgdc.UUCP (Dick Gill) writes:
= >.....  Of course, noone should expect that the Unix [WordPerfect]
= >implementation will deliver the same responsiveness, color and ..
= Why not? The reason can't be that no fast UNIX workstations
= with enough color-graphics capabilities exist........
= Anyway, WP is one of the first succesfull PC packages that has made
= the step to UNIX. Congratulations. Who follows?

A year ago, a project I was on was evaluating UNIX wordprocessors
that also ran on DOS.  WordPerfect was being done at the time (may
have been betas?), a garage-shop made Arrow which was really nice
and came from the UNIX side first, and there was Samna, which I
tried out personally.  I'm going to comment about Samna's
implementation and use that to make some general comments about why
it may be easier to do a good editor on a PC than on terminals.

[ Disclaimer: You've heard disclaimers before.  This is one of them. ]

Samna *reeked*.  Some of its problems were because it was their
first UNIX implementation, and may be fixed by now, but some were
just inherent.  A critical problem is that Samna is an old editor,
and the original implementations were made to fit on small PCs, with
overlays and stuff that us old-timers remember doing on PDP-11s, and
to adapt to the modern world (or even the semi-modern 640K) would be
a major re-implementation for them, restructuring *everything*.

Samna is a character-oriented editor with several
lines of menu at the top of the screen, which are context-sensitive
and tend to change with about every other command-letter you type.
I don't remember if it was modeless or mode-explicit, but when you
were typing something it assumed was a command the cursor would go
to top-of-screen and write stuff there, which is rational.

Unfortunately, it couldn't do windows right, and constantly had to
redraw the entire screen from cursor down.  This was exacerbated by
the fact that the menu at the top kept changing from two lines to
three, causing everything on the page to shift down by one line (dumb)
which it did by redrawing instead of insert/delete line (real dumb),
even though the terminfo description included insert/delete line.
At 19200 it was too slow to be useful; I'd rather use ed.
On the console of the PC (16 MHz AT&T 6386) the screen could scroll
characters at about 100,000 baud equivalent, and Samna was still ugly.
<end insult-the-product mode>

One basic difference between PC/Workstations and terminals is the 
difference in speeds of direct access vs. communication.  On a terminal,
the way to gain efficiency is by calculating the minimum set of
commands to change the screen from what it was to what you want.
On a workstation, the screen is right there in the frame buffer,
and it's much faster to just write characters where you want them
than to think about each location at least three times.
Sometimes you know what the optimization is, as when the user types
<INSERT LINE>, so you call a subroutine that does that, but usually
you just redraw.  This makes it very hard to move a PC-oriented
product to the UNIX/terminal world, because the assumption that to
change the screen you just write to it tends to be all-pervasive,
even in well-written modular code.  In particular modular routines
for screen-handling are probably much lighter-weight than Curses.

In Samna's case, the original was probably written in assembler, and
the modularity was mostly done to make things fit, though they've used
it well to add features.  They apparently never used an insert-line
module; I assume they just called the copy-line routine N times,
resulting in N little calls to curses, each redrawing a line.

Another difference between MS-DOS PCs and UNIX terminal system is
that PCs have a lot more keys than the traditional terminal, and you
can use these to improve the human-factors aspects significantly.
The modes-versus-modeless argument really tends to mean "How can I
tell a command from input text", which is easy when you have a lot
of Function and Arrow keys; the ^F key is always a ^F, because
there's a forward-arrow-key to use for forward-cursor commands.
Input is always ASCII, while terminal scan codes give you a lot of
out-of-band options like control-alt-rightshift-F3, even if Wordstar
does use the ^K key as a function key.

Some of these arguments go away when you're talking about genuine
workstation word processors for UNIX, such as Interleaf and Frame,
and Interleaf has been ported to PCs (big hulking ones only, but PCs.)
But most UNIX products are oriented toward character-oriented
terminals, where WYSIWYG means you only get monospace ASCII; there
are some products like CrystalWriter and WordMarc what live in this
environment, but it's pretty limiting.


To make money in the software business, you either need to have a
large market for a low-priced product, or a high-end product that
can support high prices if your market is small.

The high end of the UNIX text processing market is people who
already have troff or TeX, with zillions of powerful features that
few of the high-end PC systems can duplicate, where users know that
what they work with on their terminals will never come close to what
their laser printers can draw.  A character-based WYSIWYG system like
CrystalWriter can do drafts of straight text and produce nroff-code
output, but if you're doing mathematical equations your ASCII
terminal doesn't have the character set you need, and even a
132-column mode terminal won't let you draw really hairy tables.
(You know the type, where you're using 6-point landscape to make it
all fit in a page with lots of T{ T} and weird boxed sections.)
For that matter, Microsoft Word on a Macintosh won't let you create
a complex table as easily as tbl.  Maybe Interleaf or Frame will.

But the low end market for UNIX WP's isn't big enough, because most of
us roff-users get too frustrated by a system that can't keep track of
numbered lists on the fly, so we keep using vi/emacs+TeX/*roff.
It's tough to do a cheap low-end product, because the roff-users and
PC-market raise the functionality standards for the low end, 
because it's harder to build a great product for terminals than PCs,
because (until recently) a UNIX development shop cost more than a PC
development shop, and because you just *know* that three months after
you ship Foo-Writer, some college student will use it, like it, and
write an Electric-Foo-Writer Gnu Emacs mode which she'll post to
comp.sources.misc.  It will be slower than your product, but it will
have more features, and on a 386-box the speed will be ok.

The alternative channel is for a "big" company to port an existing
system from PCs or VMS, which they may be able to do cheaply, or for
some major market player (SCO, AT&T, IBM, SUN ..) to sell a word processor
powerful enough to pay for but cheap enough to buy when you're
already buying their UNIX or their 386 hardware.  Most of us have tried,
but the fact that this discussion keeps coming up is evidence that
none of the products has gotten significant market penetration.
-- 
# Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
	# also cloned at 201-271-4712 tarpon.att.com!wcs 

#			... counting stars by candle light ....