Is there any wordprocessor in unix

Greg A. Woods woods at eci386.uucp
Thu Jul 27 03:24:35 AEST 1989


In article <2557 at cbnewsh.ATT.COM> wcs at cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) writes:
> [.....]  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.

[ This is an aside, not really related to the thread.... ]

What's wrong with making special effort to determine how the various
versions of curses keep their in-core screen images, and writing to
that buffer, just like you write to a PC-screen buffer?  This has it's
problems, but it means you can skip the crud on top of curses that
fills the buffer in the first place.

For that matter, skip all of curses, and just use the termcap/terminfo
routines to read the existing database, and re-implement the curses
screen buffering/optimization scheme.  There's simply no excuse for
sending that much data out a port, except pure lazyness.

It all depends upon what you are starting with.  You can easily use
all of curses if the editor portion of your code is structured like
the guts of vi.

> 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.

I seriously doubt it.  The smart terminals people buy today, and even
in the recent past, almost always have more than 10 function keys.
Even my VT-100 has 14 function keys, plus cursor keys.  The difficult
thing to find consistently is a meta (alt) key.  I won't mention that
terminals usually have far better keyboard layouts...

> 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.

Yes, this is the real problem with moving some applications from the
PC to a terminal.  Of course, I always been quite disgusted with
applications that used the scan codes anyway.  There are much better
paradigms than <CTRL-ALT-RIGHTSHIFT-F3>.  Over use of multi-key
combinations shouts "POOR USER INTERFACE DESIGN!".

As you said (in the paragraphs I've deleted), even though there's a
lot of noise being generated, the market really isn't big enough to be
worth while.  I strongly suggest what's required is a good text
editor, with some of the editing features of the best word processors.
Since I find Jove does more than I need, I'm at a bit of a loss when
it comes to identifying the requirements perceived by those who design
things like WordPerfect.

Once the text has been input, wrapping troff or TeX around the
paragraphs is a reasonably simple task.  Even someone who can barely
operate a typewriter can be taught to enter text in such a way to not
increase the effort required to format lists and tables and such.
Once you've got them that far, a couple more hours and they can put
the troff/TeX requests in themselves.  I've personally taught several
people this skill, and have even managed to teach them vi or emacs as
well.

WYSIWYG is a definite no-no in Unix land.  Even going so far as
attempting a real-time simulation like WordPerfect tries, costs far
too much in CPU and I/O.  The simple emacs clones (like Jove) are
resource intensive enough.

The one thing which might have an impact would be cheap graphics
terminals, be they X-Window, or BLIT style.  At home I have a DMD5620,
and I can set up troff to proof to a window every time I save my
file.  It should be quite easy for someone with sufficient motivation
and knowledge to write a programme like 'proof' for MS-DOS.  You might
even be able to get all of layers running on a PC, though even VGA
resolution is only satisfactory for useful windowing.  There certainly
are enough PC's out there that would make good terminals.
-- 
						Greg A. Woods

woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET}
+1-416-443-1734 [h]  +1-416-595-5425 [w]		Toronto, Ontario CANADA



More information about the Comp.unix.questions mailing list