Xref: utzoo comp.unix.questions:15168 comp.editors:883 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!apple!rutgers!dptg!att!cbnewsh!wcs From: wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) Newsgroups: comp.unix.questions,comp.editors Subject: Re: Is there any wordprocessor in unix Message-ID: <2557@cbnewsh.ATT.COM> Date: 25 Jul 89 04:47:09 GMT References: <4856@macom1.UUCP> <248@arnor.UUCP> <1044@kuling.UUCP> <8161@bsu-cs.bsu.edu> <330@umabco.UUCP> <228@psgdc> <1143@ssp15.idca.tds.philips.nl> Reply-To: wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) Organization: Your typical phone company involved in your typical daydream Lines: 129 In article <1143@ssp15.idca.tds.philips.nl> jos@idca.tds.PHILIPS.nl (Jos Vos) writes: = In article <228@psgdc> rg@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. 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 , 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 ....