On Dec 11, 2014, at 5:38 PM, Mark Wickens <mark at wickensonline.co.uk> wrote: Wordstar. Liked it on the Rainbow, really well. Simple control sequences, fast, reliable. But, I didn?t use many of them; the only other I remember was Scripsit on TRS-80 which was so-so. - Mark

On Thu, Dec 11, 2014 at 11:38:35PM +0000, Mark Wickens wrote: Editors look deceptively simple to write, but they're actually quite hard to do well. I started using Emacs in 1995 once x86 hardware became cheap enough that I could afford to buy some to stick Linux on it to get my own Unix box to play with. I've never looked back :) For letters, documentation, and other word-processing tasks as opposed to writing code, I normally just edit LaTeX documents with Emacs, but for trivial documents that don't need heavy editing I'm finding that TeXShop.app is sufficient and has a faster edit-compile-preview cycle than the Emacs-based workflow. Previously, I used some reasonably powerful "programmers' editor" on the Amiga, the name of which I forget, and before that I had toy 8 bit systems in which the "editor" was the BASIC interpreter's REPL (as we would now call it). I did quite like Wordwise on other people's BBC Micros, but I had a crummy old Acorn Electron. Have a look at http://en.wikipedia.org/wiki/Wordwise The closest to this would be Wordwise. Wikipedia notes as a feature that "The program was *not* a WYSIWYG text editor", but does not really explain it terribly well. The text-editing mode used "graphics" MODE 7, which was a 40x25 character-mode display provided by a Teletext character generator. Teletext supports in-band control codes to set colours, and the control code is rendered as a space. Wordwise used this as a feature in that a command would be prefixed by a set-colour code (I *think* it was green, but it was 30 years ago!) and returning to text was set-white. So the commands were nice and obvious in the document, being in a different colour and not smushed in with the text. The preview mode used "graphics" MODE 3, which the OS presented as an 80x25 text mode without graphics support. What you *actually* got was 25 lines of 640x8 strips. It's basically a hack to reduce the display memory requirements the first place, and the MOS+DFS swipes 6.25kiB of that. In theory one could write straight into the framebuffer to get proportional text, bold, italic and underline, but Wordwise just used the OS calls, and so its "preview" was just unstyled text on a grid, but at least it matched the lousy consumer-grade printers of the day so they got away with it. If you run with the Wordwise approach, you can "preview" to CGA's 640x200 graphics mode which allows you to render styled proportional text in arbitrary fonts, which cannot be displayed in VGA's text mode. VGA text mode will only give you bold plus one of underline, italic, or alternate font set (italic being a special case of this) and is of course fixed-width. Even terminal emulators on full windowing systems tend to have limited support of ANSI control codes: the one I'm composing this response in will not do italic, for example. (On the "upside", it has excellent Unicode support and 24 bit colour. It's almost a waste that I mainly use it for black-on-white US-ASCII.) If you want WYSIWYG, you will have to use a graphics mode, or constrain the printed documents to the same limitations as VGA. This is a *lot* harder or will produce substandard results, so I strongly recommend against it. Consider also that if you're going to print proportional text, you need to know the width of all of the characters so you know where to insert line breaks. This is likely to also affect preview mode since the glyphs in your display font may be the same size. I told you this is a harder problem than it initially seems! The reason that Microsoft Word is a bloated lumbering bug-infested monster isn't *just* because Microsoft can't write any other kind of program, but because although most users only use 10% of Word's features, it's a different 10% for everbody and there's not much overlap. In a related vein, I'm occasionally prompted to fiddle with IDEs, causing a groan because they are inevitably terrible editors. They typically claim to be Emacs-like but miss the point that I use Emacs not out of habit because I'm used to the key bindings for navigating round and manipulating handfuls of characters, but because it contains some quite powerful whole-document tools that don't exist elsewhere. Supporting the likes of C-n, C-p no more makes it an acceptable substitute for Emacs than Nethack's use of hjkl makes it a replacement for vi.