Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 7/7/83; site rlgvax.UUCP Path: utzoo!linus!philabs!seismo!rlgvax!guy From: guy@rlgvax.UUCP Newsgroups: net.unix-wizards Subject: Re: Broff and a proposed net project Message-ID: <946@rlgvax.UUCP> Date: Tue, 2-Aug-83 13:08:52 EDT Article-I.D.: rlgvax.946 Posted: Tue Aug 2 13:08:52 1983 Date-Received: Wed, 3-Aug-83 23:37:13 EDT References: <3123@arizona.UUCP>, <5276@mcvax.UUCP> <852@rlgvax.UUCP>, <519@mit-eddie.UUCP> <938@rlgvax.UUCP>, <530@mit-eddie.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 124 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