Favourite text based word processing software

[Peter Corlett]

On Thu, Dec 11, 2014 at 11:38:35PM +0000, Mark Wickens wrote:
> I'm toying with the idea of writing a simple word processing package along
> the lines of Wordstar for my Retrochallenge 2015/01 entry.

Editors look deceptively simple to write, but they're actually quite hard to do
well.

> I have used many word processing packages over the years on many machines
> from 8-bit machines to mainframes. Within the following bounds I'd love to
> know the packages that have been the favourite of list members over the years
> and why.

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

> If I implement this I'd be looking to keep within the following bounds:
> * text only - ideally support VT terminal 80x24 or 132x24/36/48 or DOS
> 80x25 display size.
> * two printer drivers - text only and Epson LQ (or possibly IBM Proprinter)
> * support small range of printer specific fonts
> * support proportional text
> So a little more than a text-editor but only enough to support simple
> formatting and styles (bold, italic, underline for example).

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
from 20kiB to 16kiB, which is helpful when the base machine only has 32kiB in
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!

> Ideally I'd like to implement a clean, logical design without many 'bells and
> whistles' concentrating on the core functionality.

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.