I'm in the process of having another attack on "Rule 34", and I thought some of you might appreciate a rant about tools.
The business of writing novels is rather unlike most other office jobs in that it involves producing long — but structurally simple — text documents which may then be shared with other organizations over a period of years or decades.
Most business literature is ephemeral; even process manuals are seldom expected to last more than a double-handful of years, and the majority of files are typically dead of old age after 18 months. A novel, in contrast, may be reprinted in the distant future. You may be unsurprised to learn that I'm therefore positively allergic to Microsoft's habit of changing file formats in new and excitingly incompatible ways every year or two.
But that's not my only reason for disliking Word. It — or something capable of extruding its files, like OpenOffice — is well-nigh unavoidable if you want to work with other businesses, but it's not an ideal tool for writing books.
Word is descended from some of the earliest WYSIWYG document processors, developed in the XEROX research labs during the mid-1970s. There was some argument in those days over the best way in which to manage styled text. One model, used in non-WYSIWYG word processors such as WordStar (and document macro languages such as ΤΕΧ and nroff) is to view the text as a stream of characters, and to include codes that change the characteristics of those characters in line with them (for example, to switch text into italics, or to switch on underlining — and to switch off those characteristics). The problem with this technique is that it conflates document content with presentation. Moreover, the more formatting (presentation) mark-up you insert into a document, the less useful it becomes as online data. It's also difficult to maintain consistency within compound multi-file documents (such as books or magazines) if the authors are manually specifying things like typeface and font size and line spacing within the text. An alternate model is to therefore use a style-sheet driven formatting system, and this is how virtually all modern desktop publishing systems work.
Guess what? Microsoft Word does both (inline markup and style sheets). And it does them badly, allowing users to override paragraph styles with local inline markup (or, indeed, to drop styles on top of marked-up text).
Given my general aversion to Word, you probably won't be surprised to know that I prefer to use a programmer's text editor and a simple macro-based language for formatting text. Back in the day, I wrote several novels using: Vim as my editor (vi keystrokes are hardwired into my fingertips — I've been using it since 1989), POD macros (Perl's Plain Old Documentation format), a Makefile to generate up-to-date output formats such as RTF, PDF, and HTML from the podfiles, and rcs to track changes. (With an entire novel occupying a single file, rcs is more than adequate for the task.)
Since 2006 I've been led astray by editorial fiat (and the need to exchange documents), firstly into extensive (mis-)use of OpenOffice, and then Scrivener. Scrivener's text editing capability is not good (it basically wraps around the standard Mac OS X rich text handling library, so that it processes RTF but can't cope with style sheets), but that's not what it's for; it's a tool designed to allow a writer to mess around with the deep structure of a book, tracking and editing multiple plot threads and keep notes and cross-references that won't appear in th final generated output. (This was really, truly, a life-saver when I was working on the last two Merchant Princes books; with 19 major character threads to keep track of, marshalling everything and keeping them all on track was the hardest part of the project.) But Scrivener annoys me. Not because it's bad software — to the contrary: it's very good at what it does. But it makes for proprietary lock-in: a commercial program that runs only on OS X. Yes, if you've got an RTF editor you can dig the guts out of a Scrivener project, and it's happy to import and export data. But something in me feels a little dirty at the idea of using a non-cross platform proprietary tool. And the text editor really isn't a patch on vim.
POD is a little lacking in features and I'm trying to teach myself Python as a side-project, so I've just spent a day exporting the first 60% of "Rule 34" into reStructuredText, encountering a nasty little bug in OpenOffice 3.1 for OS X along the way (backreferences in regular expression search/replace are sometimes replaced by reference, not by value, i.e. you get "$0" inserted in your replacement text instead of whatever $0 points to). I'm going to write the rest of this sucker in vim, because when you get down to it there is only One True Text Editor, and I've got enough of a handle on the structure of "Rule 34" that I don't need the training wheels. Also: the files take up less space, are easier to mess around with by hand, and I can work on it on just about anything that's got a keyboard and an output device. When I have some spare time I'm going to poke around with git, but pointing a distributed SCCM at a novel is a bit like using an ICBM to swat a fly.
But anyway: sometimes you just don't need WYSIWYG. Sometimes WYSIWYG is a snare and a distraction. And writing a novel is one of those times.
Your choice of a text editor is kind of like a tattoo, isn't it? After a while you have to look back on that decision you made when you were fifteen and realize, "yup, that's just never going to go away."
It might be interesting to see you sketch a design for a Scrivener-like tool - important features, things it does wrong, etc.
jwz: Yup.
Mind you, I've tried going over to the dark side. But every time I used emacs for more than a week I began getting shooting pains in my wrists. So I stopped doing that, and they went away.
i guess you reported the mentioned bug?
To a good first approximation, I never need WYSIWYG. I continue to do everything in The One True Editor (a different one from yours, but I'm not religious about it). Code, email, web content, fiction, poetry, my father's memoirs, business letters, the company accounts, everything.
Layout is, pretty much always, a snare, and certainly a terrible distraction from creating actual content. Most of the greatest works in English - novels, plays, poetry, journalism, stories - were written with pen and ink, and most of the rest with a typewriter. The main advantages of computers over typewriters, for composition, are (a) ease of drafting: deletion, rewriting, cut-and-paste, and (b) ease of storage, transmission, and duplication of the result. And I guess (c) no inky ribbon. The main disadvantages are (x) ease of dicking around with layout and markup, (y) ease of accidentally deleting hours or months of work, and of course (z) printers.
Besides which, in most forms of writing, there's essentially no style markup beyond the occasional use of italics.
If you have to use markup (e.g. for tracking your character threads, an excellent example) then it is pretty easy to use some trivial markup (e.g. some kind of XML), and to use little Unixy tools to process it. I used to use one of the outlining modes for Emacs to do that kind of thing.
Did you use a meta key? I used to have occasional wrist problems, until I started having to use Emacs a lot over 7-bit connections, and discovered that ESC is pretty much exactly as good. Haven't had wrist problems since. I think the multiple-modifier-keys style of working isn't great with modern keyboards, especially laptop ones. Switching to using ESC was really easy too. Some hide-bound Emacs users will insist it slows them down, but I suspect any effect is minuscule.
Utterly fascinating. I don't think I ever thought about how you kept track of the various characters (and now I'm really curious how Erikson does it). For some of the longer things I've written, I've had comments at the beginning of the file.
As for editors, I'm a weird one, even by the standards here; I usually use nvi, but I also use emacs for longer sessions, and I can happily use ed as well.
But... But... git scales so incredibly well. I use it most often for tiny projects, because distributed version control systems are perfect for small projects. It gives you the clean workflow of a copy-modify-merge system (instead of the eye-gouging workflow of RCS/SCCS), and it is self-contained. You type 'git init; git add .; git commit -a' and your project directory is also your repo. The directory is everything, and you have a working copy at the top level just like you would without an SCM.
Finally, you can ignore all the distributed SCM features, but it does end up acting as a convenient way to move your work between computers--although, you probably want to create a "master" repo that only gets pushed and pulled from. git doesn't like it when you push to a repo with local, uncommitted changes.
@JWZ: yeah, I even made that decision at 15 (ok, 16). I tried emacs first--since it was closer to what I was used to already. However, it took better than 10 seconds to start up on a Pentium 120. vim started up in less than a second on that machine (back in 1998). That's it. That's the only reason I'm in our proprietor's camp rather than yours. In fact, if I had known about microemacs or some of the other light weight emacs forks/clones, I might never have attempted to learn the vi interface. As it was, the options, as the appeared to my n00b, teenage self, were Emacs or Vim. CHOOSE.
I periodically try swapping out software in my 'stack', but nothing has ever replaced vim. It's got about three too many killer features--and everything else is always missing one or two. It's just never going away. Not even if I commit the sin of rolling my own.
Perhaps, but are you sure it isn't more like using dynamite to catch fish? That is, overpowered, but undeniably effective? If you're not trying to actually share edits with folks, git is more like a clever filesystem than a SCM.
Not a Mac, so no Scrivener for me. I use Liquid Story Binder for writing. It's got WAY more features than I need, and they aren't well (or at all clearly) organized, but it provides what I need: primarily a full-screen editor and the ability to inline/offset notes without command sequences, menus, or pulldowns. Also no proprietary crap, just RTF files.
There are a number of other, simpler full-screen editors out there, but most are just a bit under-featured. I'm plenty comfortable with a VT100 terminal but a purely command line environment for writing is just a bit masochistic for me personally.
I don't want to take anything away from git, but I would paint the bikeshed bzr coloured. I'm not a hardcore kernel hacker, so git is not my friend. I do just want to track changes in simple things, so bzr is my friend. It helps that I work with the bzr folks, but I was using it before that happened, so my bias isn't completely horrific ;)
(I also don't want to start a flamefest about DVCS tools - git is a great tool and I think there is a place in this big universe for git and bzr and hg and svn, but never Perforce)
Sean, you are not the only ed-user around here. I use it primarily for commit messages these days, but I spent a couple years working on embedded devices--ed worked even in the strangest setups. I love ed.
Git has the advantage that you can then use Gource to visualise it.
start up What's that? $ ps -u -Unb USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND nb 14454 5.5 11.7 54216 29956 p3 R+ 1Aug09 606:55.11 emacs ... Huh, only 160 days. Maybe we had a power-cut back in the summer.
Nice try Nick, but the tattoo is there and has survived multiple Laser removal treatments.
The P120 was my Dad's computer. I bought a second harddrive (a monstrous 3GiB!) to install Linux on. Dad needed to run windows regularly. So yeah, start-up time still mattered, and the introductory guides (back then) didn't mention the "just don't quit" solution to start-up time.
Again, nice. I say this as a screen user.
I'm curious as to how publishers see these things. Presumably you have at least a bit of leverage, but do they bend unestablished writers over the barrel of MS Word?
I feel for you man, I really do. I live in a world of a similar, and even nastier set of documents: Regulatory/scientific writing at pharma companies.
These documents not only have long lengths and long lifespans, they tend to get frobbed into subsequent studies and protocols and reports, and any subtle corruption in one becomes magnified through glorious reuse.
And Word is pretty much the only choice in the corporate environment. Don't even think of suggesting an alternative: "We've already paid for Word, make it work there."
There's some XML stuff making inroads (the format of the dead-sea-scroll jammed into drug boxes is now XML), but it's typically a last-minute conversion at all but a few companies.
DITA is another area starting to emerge, but it would be a lousy novel-writing format: much better for those tech manuals you used to suffer through.
Writing novels in vim + POD, this just makes you even more awesome in my mind, as those are tools I use every day, sometimes even for writing fiction :)
Frankly, you are all barking up the wrong tree.
The answer is Emacs, but not necessarily for editing (you can always use vi-mode for that. Or just vi. Or sed. Or e).
Write the novel in emacs lisp, such that the outermost function evaluates to the novel text -- if you're clever about where you put your hooks, then your mark-up can be adapted on the fly (and individual character threads are a mere evaluation away).
Or you could just use raw lisp or scheme. A novel is, after all, just a list of words :)
Once you finished your novel, I'm sure it wouldn't be too much harder to include an email client in the sequel.
Three for three here. I'm a VIM user who develops Python code which is then stored in git.
I personally prefer git over other SCMs for programming. Git's strength is branching and remerging. Do you do a lot of branching, Charlie? IMO, Git seems like overkill for writing stories -- but I'm not an author.
Mercurial may be a better choice in that the user-facing portions tend to be much easier to learn and remember. It took me only a couple days to learn Mercurial but I'm STILL mastering git after 8 months! Git add-ons tend to be more prolific however.
I couldn't agree more on the choice of VIM and Python.
I use Vim, Pod::PseudoPod (an extension of POD), and Git for my novels. It works very well.
Unlike the "one file per novel" approach, I use one file per scene, then use a small Perl program to weave everything together into chapters. This makes moving scenes trivial and diffs much more manageable.
When you're simply writing text, how import is it to have formatting/styles/Proper Editor vs simply having something really really simple like writeroom/pyroom/OOM etc?
ObNote: While I write most of my email and do all short file editing in a vi clone (not vim), I use Emacs when I'm working on something where I'm likely to be thinking or distracted beyond the scope where I can reasonably remember what mode I was in. I guess this means I can troll both camps, but I get to be particular snide at Bram when I see him.
After getting laughed at for using VIM and vi instead of emacs, I'm delighted to hear you're writing books with it!
HA! Vim! I knew there was a reason I liked your books :D
http://stochasticgeometry.wordpress.com/2008/06/19/emacs/ http://stochasticgeometry.wordpress.com/2008/06/26/emacs-fail/
BTW, git or mercurial (I use the latter, but even Linus has said they're fairly equivalent) offer some major advantages over RCS, not least of which is that it's a lot easier to do offsite backups of work with them, not to mention the ease of jumping from machine to machine -- and the decentralised nature of the repository means that if one machine croaks, you're not dead in the water (helps if you have a cron script on every box to hg pull; hg update critical repositories into backup directories every night of course!)
The interesting thing about the comments here is that it suggests everyone commenting on this blog comes from a Unix background (I'm including Linux, and I'm aware Vim has been around on Windows for donkeys, but that's more for our benefit).
I've been going the other way, and trying to learn Textmate/E-Editor - I think a lot of us have an instinct to use the simplest tools possible (on the rightful ground they are the most portable / available) but I can see the productivity benefits of using something like Textmate to its potential (which means, like vi, creating a lot of custom macros/snippets).
(On the other hand, I'm still definitely an editor, rather than IDE person)
To those who're discussing SCCMs, I do no branching, and work on one file. All I need version control for is an "undo" feature that works across edit sessions. Distributed repositories, configuration management, all that stuff -- useless. RCS has an excessively rich feature set for my needs! And I really can't afford to be messing around with something where I have to learn spurious crap before I can make it do what I want (i.e. provide cross-session "undo").
Actually, I tell a lie: there's a situation where I do need to diff two branches of a file and look at the changes. Alas, it's to compare the copy-editor's work in Microsoft Word to the Word document I sent to my editor, and there's only one tool for that job: two, if you count OpenOffice.
(Do not get me started on the inadequacies of AbiWord. Suffice to say, if you want to find out why I don't use it, locate a 100,000 word text file, import it into AbiWord, scroll to somewhere in the middle of the file, and start typing.)
Apropos TextMate: I'd have been more inclined to try it if I could figure out how much the fricking thing costs. At least, without buying a copy. Ahem.
I'm using Sphinx (a ReST markup tool that is used for the core python documentation) to rough out my PyCon talk. It has features you don't care about (are you unit testing any parts of your book?) but is great for mixing code and documentation. The Word templates technical book publishers make you submit in are a nightmare by comparison.
Flattering aside: I first heard about your stuff over beers at a past PyCon; and that was before you starting dropping shout-outs to py3k in your books.
There's an opening for a word processor that works in HTML/CSS, probably with a graphical top, a noddycode layer, and then raw code.
My partner is nontechnical and constantly has to deal with collaboratively edited, heavily formatted MSWord documents in academia, and it's truly astonishing the degree of pain involved. Not only would a version control system help (although, vertrol is a bit like These People Just Need A Honky - everyone who does it thinks it's the solution to everyone else's problems), but MS Word is just so painful. It's riddled with some of the worst usability antipatterns you can imagine, especially that it tends to change things because it's designed to assume that you should want them. And it's hellishly implicit; you can't just hit the right keystroke command and remove the bloody annoying spare section break. You often can remove one of those graphically, but not always.
Jeff Atwood did a really nice piece about WordPerfect and its wonderful REVEAL CODES command a while back; WP was the first wordprocessor..the second, actually, after LocoScript, that I learned to use. And REVEAL CODES was one of the best features in any office software ever. You hit the keystroke and everything went explicit, and you could then fix anything.
TextMate costs €39.
I think I actually paid for it once, years ago, but I haven't used it recently. And you can use it for 30 days before paying.
(This isn't a particular recommendation for it, I just have the typical need to answer questions to show that I know things.)
Charlie, have you looked into Flashbake? thats an Open Source tool created by "the Command Line" podcaster Thomas Gideon,( http://thecommandline.net ) that Cory uses.. it backs up a snapshot every 15 minutes of your current work + a configureable bit of other info if you wan. I don't remember which dvcs it uses underneath. but I'd be guessing it wouldn't be too difficult to switch it out.
It answered Cory's question about what Lit students are going to look at to understand an authors writing paper in 50 years. He includes recent websites visted, blog posts made, tweets tweeted etc..
I'm just guessing, but I suspect more PhD's will be gained on Cory's use of this than for other authors that have moved to an entirely electronic editing environment. (things that comments in the manuscript margins would have given students a hint at in the age of paper).
Most of my writing is coding, so a plain text, syntax highlighting editor is crucial. Unfortunately I moved to Nedit several years ago, and I've seen no updates to the code for about 5 years. - I've been meaning to move back to vi (well ahead to vim I guess) someday.
BTW .. I don't know if your editor can take such a risk, But I'd probably the first book in any new series you started.. For myself, I'm looking for insights into the future. Which is why I rank the things you, Cory and David [Brin] above the space opera stuff (not to say that I'm not reading any more space opera though I think Dune has had its run.. )
Has he thought of crowdsourceing this? give us the option to put a tenner advance payment on the one we want to read first? Which ever one funds the advance first wins?
thanks for writing and blogging. Jonathan
Have you looked at the work-in-progress archiving scripts that Cory is using?
Jonathan David: Your [generic "you"] future doctoral thesis on the making of my work is not my concern.
Or, to put it another way: as an author, my responsibility begins and ends with creating a text that does what it says on the tin -- in my case, delivers commercial entertainment to a particular audience demographic (who happen to be smart geeks). One aspect of keeping this demographic entertained is to challenge them by providing thought-provoking insights. But you shouldn't mistake me for some kind of prophet.
As for scholars doing dissertations about my work ... I am not responsible to them. I owe them nothing. Their activities are entirely irrelevant to my responsibility (see above), and while I see no reason to be obstructive, I'm not going to inconvenience myself on their behalf.
Charlie,
OS X's text system (and thus, probably Scrivener) supports emacs-style bindings, including kill rings and similar. Thus, when I'm typing this into Safari's text box, I can use things like Ctrl-K to delete the rest of a line.
There's a good article at http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html which describes the text system, obscure defaults, and how to modify key bindings.
By adjusting the keybindings, perhaps you can make the OS X text system on your machines be more vim-like.
Matthew said:
You think you are joking. You haven't seen Skribilo.
(And, no, I do not advocate writing a novel in it!)
The Unix hackers I used to know had some sort of macho thing going about how short the name of their editor was. Hard cases used e. Normal Unix dudes used vi or some other two character editor. Three letter editors like vim were for pansies, and anything with a longer name made you a (spit) user.
Me, I wrote my Masters in LaTeX via gnuemacs on a Sun workstation, and my Doctorate in LaTeX via Word on a PC with a Unix emulator (xwin-32) that allowed me to hook into the campus network and its various LaTeX and BibTeX compilers. Yes, I was a user.
I'll also add that as far as I could tell, gnuemacs could do anything if you hit enough twiddle reverse-beebop splat control keys. I'm sure the nuclear lauch codes were in there somewhere.
@Alex: I would really strongly recommend against using HTML/CSS.
The problem is that HTML still mixes too much presentation in with its coding. It's not as declarative as it claims to be, even with style sheets.
If you don't believe this, try getting an index for an HTML document. Then try doing it with LaTeX... ;-)
@Charlie: Just curious --- does LaTeX have the TeX drawbacks you refer to? I think of it as being brilliant for getting consistency across different authors (not your problem, I know) by imposing a good level of abstraction over presentation.
I prefer LaTeX over all else, but I write technical stuff, often with equation-y things and have co-authors (so concurrent edits in a revision control system are great).
Sooner or later WYSIWYG always blows up in my face, and it just never scales to multiple authors.
Cheers for sticking to RCS --- you've made your saving roll against software for the cool kids.
Me, I'll just keep writing in Word.
Yes, it sucks compared to any theoretically optimized text editor out there. I totally agree. I even preferred WordPerfect, about 10 years ago, before they started screwing around with that, too.
So what? I've been using Word for over 20 years. It's like any 20 year old relationship--you learn how to accommodate the problems.
Unless someone can demonstrate to me that I'll radically increase my productivity by switching to something else, I'd rather focus on writing than on mastering a different system.
I find this a little weird. I've been using word since the mid-90s when I switched from Word Perfect and have had no issue with losing access to, nor formating from any of the files of old scripts, unsold novels and short stories I have.
Some of the WP5.1 files are a little weird, but certainly the Word for Windows 95 onwards stuff has worked without a problem.
My real issue was with the Amstrad files which I ended up retyping in about 1992. I've not lost anything since I moved to a PC and Word.
I confess I use Pages on the Mac, but as a teacher I'm closer to a business user than an author, in that I'm writing short documents that will be updated to superseded in a handful of years. Most of my stuff gets converted to PDF anyway, as that's the best way I've found to move it to the school's Windows XP system* for printing.
*Recently upgraded from Windows NT!
Thanks for the heads up on Scrivener, Charlie. You might want to check out TiddlyWiki as a simple to use and maintain personal Wiki, that does not require server software. Everything fits in the file itself.
TiddlyWiki http://www.tiddlywiki.com/
I'd tried using the home version of WikiMedia, but lost everything in the update blues.
Word certainly has its uses. I wouldn't use it to create HTML files - I've seen the code it puts out, and you have to do a lot of cleanup to get it to anything reasonable - but for text docs, it's okay. I'll admit to turning off a lot of its overly-helpful options, though. I also run with hidden characters turned on, so I can see tabs and spaces.
I did a manual for work in Word 5/95, and just for fun did one version as a master document, to find out how that worked. I learned a lot about templates and formatting and inserting images. (The result is still in use, with updates, eight years later, although I don't think they understand about the templates and what they're for.)
JulesLt@24: Windows for donkeys -- is that different from regular Windows?
Charlie@OP: What does Scrivener give you that you couldn't get with two files? One file holds the novel's text, and the other the outline/character map/notes/xrefs/whatever. Both edited in vi.
Of course, then you'd need a new VCS to handle two files. (-:
I use a not-necessarily-for-programmers text editor: Ted Notepad.
If I need to have something in Word format or in RTF, I import it into Open Office.
kbob: I suspect you underestimate the importance of having the meta information at your fingertips along with the raw text of the book.
On a more general note, what would a revision control system optimised for writers instead of programmers look like? Well for starters, the atomic unit would be the word instead of the line. Currently, all the revision control systems look at line-by-line differences, as a proxy for the syntax tree diff that programmers really need but can't get at without embedding a full compiler into their revision control system. (Programmers tend to approximate the syntax tree they're building by splitting program contructs across lines, so this actually works fairly well in practice.)
Writers on the other hand don't work by the line, they work by the word: An rcs that understood word-by-word differences would be able to cope with Charlie's use case involving files changed by disparate copy-editors and proof readers: export the file to raw text, import it into the RCS & a word-by-word diff ought to be able to highlight all the changes in the running text regardless of any formatting or text paragraph flow changes.
I suspect existing RCS systems have the 'line' mentality too hardwired in to be able to cope with a simply replacing the diff algorithm they use sadly, or this would be something any competant programmer could knock up in a weekend. (Given darcs use of the diff as the unit of storage, that might be the easiest RCS to prototype such a system in though: any volunteers?)
Phil: I think it'd be important to also track punctuation -- including hyphenation, both manually and automatically applied -- and basic formatting (a non-issue in source code, unless there are now languages out there that use boldface to issue compiler directives :).
rpg: LaTeX has several huge drawbacks for writing novels. First, it's cumbersome and huge -- I never managed to get my head around it (I've used a scribe-like system, and troff, but LaTeX is as big as or bigger than either of those). 90% of its functionality is also irrelevant to the task in hand -- unless, like Terry Pratchett, you want to put footnotes in your novels. Secondly, none of the standard LaTeX templates follow standard manuscript layout, and although there is one out there, it's for 11" (US) paper, not A4. (See also "getting my head around it".) Thirdly, I need to be able to submit a Microsoft Word, or at least an RTF, file to my publishers. LaTeX is not terribly good at outputting Microsoft-compatible file formats. Something nice and simple like POD or ReStructuredText is more than adequate, I can memorize the essentials in an hour or two, and the text is pretty much readable in your choice of pager.
allynh: Charlie was one of the first writers to play with TiddlyWiki, see his experiment here:
http://www.antipope.org/charlie/blog-static/fiction/accelerando/toughguide.html
Charlie gave a bunch of feedback, some of which has made its way into http://www.tiddlywiki.com, and the rest will bubble into a Son-of-TiddlyWiki someday soon.
Speaking of TiddlyWiki -- I notice there's a tiddler for Prism on the tiddlywiki.org wiki, but not a lot more ... does anyone know of a cross-platform portable XULRunner or Prism package for TiddlyWiki? (It'd be quite handy to have it running in its own window, rather than inside my web browser, but I need at least to be able to carry it from Mac to Linux and back. Windows need not apply.)
Just to flog a horse that's playing possum for a moment:
How exactly do you do your work using RCS? Do you move from machine to machine, do you believe in backups (and if so, onsite or offsite), do you take your work on the road with you, and so on?
If the answers to those go the way I think they might, these points might be of interest (or might not -- I still find a whiteboard is the best design tool I ever use day-to-day and they can take my drywipe markers from my cold dead hands. I'm not being a luddite, I've just not found any computer system that can beat a whiteboard for resolution, size, speed, and quality of interface...)
I'm still a WordStar fan. It does everything I need.
Charlie@46: You're right, punctuation is equally important, together with basic layout (placement of paragraph breaks is obviously important): you could use something like the rtf format as a base to work from, put into some canonical form before running the diff perhaps.
Maybe the nroff authors were right all along...
A little googling reveals that git already has something along these lines: you can get git to output a word based diff, and you can change what git considers to be a word, so given the two ditties:
and
You can get a diff that looks like $ git diff --color-words HEAD^ diff --git a/test.txt b/test.txt index 7a91a27..b56dcf9 100644 --- a/test.txt +++ b/test.txt @@ -1,2 +1,3 @@ Roses are redpink, violets are blueorange, Cashews are nutsarguable and so are you.interns.
That actually looks useful. Certainly when applied to an rtf file, which includes paragraph breaks and other formatting as text-based markup.
(The new words that replaced the old ones were also supposed to be highlighted in that comment, but I forgot to edit them. In the original git output they're coloured differently: assume there's some italic flags in there or something.)
(Getting git to optionally use wdiff instead is also a one-liner in the git config.)
(That's enough of the paranthetical additions I think.)
Given that I work with a single file and don't need branching (except for diff, in the final stage of a project), you may be unsurprised to learn that right now I'm not using a version control system at all.
Instead, I'm using rsync and Time Machine.
I work on two Macs (one desktop, one portable). Both have Time Machine drives and get backed up daily, so I've got daily-level granularity if I need rollback. In addition to the Macs there's a Linux netbook, and a USB thumb drive, both of which get a daily updated snapshot of my work (but not a versioning image). The thumb drive is attached to my keyring, so it's on my person whenever I leave the house. I periodically rsync my writing with a copy on my colo server, 400 miles away. And I squirrel copies away elsewhere. On the to-do list: a paid Dropbox account. Also on the to-do list: another Dropbox account, to be shared with my agent.
The other computing devices in the Chateau Antipope Home for Senescent Computers -- including my old iPaq -- receive periodic update snapshots, usually every couple of weeks.
Yes, I have had a hard disk fail on me without backup in the past. Yes, I have had not one, not two, but three computers die, sulk, or otherwise render themselves inoperable under me in one 24 hour period. You may therefore conclude that my approach to backups is appropriately paranoid. (Except in the case of this server: memo to self, sort out comprehensive cloud based backup ASAP!)
I'm using scrivener now (eye candy), but at one point I had cobbled together a layout using gvim (so if vim is for pansies, as one commenter suggested, I'm guessing gvim is anathema) using a few vim plugin scripts to manage novel writing. Granted, in the end I found myself spending more time tweaking it and the merge scripts than I actually spent writing my plethora of unpublished words, but still. http://www.datanode.net/?p=829 for any other gvim users out there (yes, the scripts work in vim, just not basic vanilla vi).
There is one sense in which you do use branching: it's just that the branches are the versions you send off to your editor, copy-editors, proof readers etc etc.
Branching by post (or email) in other words!
I store all my bulk writing in text files with RST markup (plus ${} annotations). I use vi/textmate for editing and OmniOutliner for project organization ala scrivener because everything Omni does is magic. I have a set of python utilities I've grown over the years mostly for ${} processing, and recently switched from svn to git + github for coding purposes, so the writing stuff migrated too.
Extra plug for OmniOutliner: It groks Applescript. Which means it groks anything I can make my Mac do including python scripts. Best example: Each project gets an inbox on my Pogoplug I can drop files onto it from any device (iphone!). A cron'd python job picks up the files and adds them via Applescript to the OO project. This includes voice memos, web links, photos, text blurbs, videos, emails - you name it.
heteromeles @38 --
In a previous life I got to take a tech writing group's Framemaker and Word away and give them an XML content management system. (The XML happened to be DITA.) The system enforced form-content separation. (It enforced topic-based authoring, too.)
Productivity increased by a factor of roughly 2.5.
That increase is in the context of a group in which half the members hated the change with a mad inhuman passion and in which the system never got used to anything like its full potential.
The biggest single strike against DTP programs for any kind of large document is that they're painfully, horribly, cripplingly non-productive while creating an illusion of utility because you can print something nicely formatted right away.
Putting all the complexity right there in front of the user in an inter-related lump rather than in discrete stages means you have to think about it, and the effort cost scales as n(n-1) where n is the number of things you have to think about. Two things is easy; four things is not. DTP makes you think about not less than four things -- sentences, relation of this sentence to the context, "does this sentence look right?", and "is the appearance of this sentence consistent with that of other similar sentences elsewhere in this document/body of work/set of deliverables?" (If you want to use "unit of text" for "sentence" I shan't complain.)
No matter how used to this people are, it really and truly slows them down. It's hard to get people to believe this even after you've better than doubled their productivity.
Graydon: you may find it amusing to know that my word count per unit time spent writing (on "Rule 34") roughly doubled once I finished exporting to reStructuredText and fired up vim -- yesterday.
Graydon@59: there are people out there who use InDesign, Quark Xpress etc as writing tools? Those are packages that a writer should never see, and which should come into the game at some point after copy-editing.
I won't go on about my history with vi. (I've been using it since about '84, and my spine knows the keystokes, not my brain.) But, while I entirely despise Microsoft Word as it is now, you're unfair to what it gave us in the past.
In '91-'92 I lived in London, and as the "working" part of my working holiday I was quite heavily involved in typing somewhere between 10,000 and 20,000 pages of contracts for the London Underground Jubilee Line Extension.
When I started, we were all using Word 5.0 for DOS, and, once I'd tweaked a few things, it was fantastic. It was not WYSIWYG, so on the screen you concentrated on the text, not the formatting, and it had excellent style sheets that let me set things up so you could pick from one of half a dozen choices for a paragraph format, and that was all you needed. I'm not lacking experience with WordPerfect, WordStar, and even nroff, and I think Word 5.0 for DOS was not only pretty darn good, but very good.
Happy times of course had to end, and they ended in my case with the CUE (IBM-and-friends' Common User Interface) version; now we had drop-down menus, colour, and so on, and it only became harder to use. Word for Windows came in just before I left and made things more difficult. Having used Word and OpenOffice a few times since, I've run to LaTeX. I've tried to use Word a few times in the last half decade or so, and I'm mystified by it now.
Word peaked with Microsoft Word 5.1a for Macintosh, circa 1990, or maybe Word 5.5 for DOS -- around 1988. The latter used IBM's standardized CUA key bindings and was consistent. Pre-CUA Word was a bit ... eccentric, to say the least.
I've had good luck with reStructuredText for technical documents, especially when combined with Sphinx (to convert to HTML and PDF). If you're working on a single large file, I imagine you just use the docutils converters, though?
Drop me a line if you have any Python questions. I'd be to help with answers.
@47 Jeremy Ruston
:Charlie was one of the first writers to play with TiddlyWiki, see his experiment here:
Ah, I missed that. Thanks...
Feòrag @61 --
Well, yes, I have seen writers deliver things via Quark and InDesign (or InCopy, poor souls), but I meant to include Word and Frame (and Interleaf, and ArborText Textra, and ....) in the "DTP" category.
Something like Quark or InDesign or (on the free side of the aisle) Scribus are Desk Top Publishing programs, all right; they don't have the editor functionality that Word or Frame or OpenOffice Writer do, they exist to do the things that were, once upon a time, done with typesetting, but Word and Frame and OpenOffice Writer do have the ability to format and flow text, and do get regarded (especially the charmingly undead FrameMaker) as DTP software. And if you say "DTP software" when selling an XML system, you're covering everything from Word through some NotePad-to-Quark workflow, so it's a handily broad brush.
Doug @64 --
I've used reStructured Text, Docutils, and a perl to implement a scenario-based authoring (demo!) system in a month. The contracting party thought they needed a tech writer. They got lucky, and I had fun.
Charlie @60 --
Amused, yes. Surprised, no. Not even a little bit surprised.
ReST has, or, rather, the python docutils have, a good XML output format[1]; you could learn XQuery and send your edits to your publisher as nicely hierarchical node-specific XML diffs....
[1] This is why it's OK to bootstrap commercial documentation systems out of it; you can machine transmogrify all your content into something else later, you're not digging the client a nice deep expensive hole.
We do what we can for a living.
One of my more recent jobs involved applying DTP quality formatting to Word documents. Using Word.
The authors were expected to cough up the text/content to the best of their ability and then my job was to make it "look pretty" (for a tightly controlled corporate brand image definition of pretty).
There are no shortcuts, not when the document potentially had multiple authors + plus recycled chunks from older documents.
Open a fresh document. Copy paste text across as unformatted text (avoiding those bloody section breaks like the plague) and then reapplying styles. Rinse lather and repeat.
Back in my first year of college I forgot how to use Word. I had been spending a lot of time teaching myself HTML, and working on web pages, and hadn't written anything in a regular word editor for a while.
Then I had to write a paper in class, and at the last minute realized I couldn't remember how to format text the way I wanted.
So I pasted the whole thing to notepad, added in the HTML formatting, and displayed it in a web browser before printing it for class.
"Word peaked with Microsoft Word 5.1a for Macintosh, circa 1990, or maybe Word 5.5 for DOS -- around 1988."
I'm personally convinced it was all down hill since version 4/Mac. Blazingly fast on an SE. Once they added the gray button bar it was all downhill as far as productivity went.
This is bringing back memories of writing papers in college and falling asleep while spell checking and trying to figure out where that word that I stupidly hit "ignore" on was...
These days, since I came back to Mac land after an extended stay in Debian, I alternate between BBEdit and vim. For whatever reason (I can't really explain why myself), BBEdit is for HTML-related things, vim for everything else (and I still end up reflexively whacking the escape key in web forms like this). Most everything I do lives in a couple of subversion repositories I set up probably 7 years ago, and I can't be arsed to switch now that the cool kids went on to git.
I'm going to have to figure out Python soon (Plone seems to make sense as a base for a consulting project I'm about to start), but you can have my Perl interpreter when you pry it from my cold, dead cliche. And using whitespace as syntax still really, really rubs me the wrong way. Ruby is nifty in a way, but it seems to encourage people to be clever beyond their reach. And if I never have to deal with Rails again, I'll die happily - monkeying with 3-5 different files to propagate every simple change is not progress, and doesn't seem to serve a purpose other than to make younger coders feel productive. If were that sort of masochist I'd code in Java. Yeah, stay off my lawn.
@Chalrie, I'm guessing you aren't subscribed to the python-dev list but it gets spammed all the time by well-wishers, trolls, and emergent AIs. I'm not sure what category the most recent nonsensical email falls into but it was a binary blob that included "REGION -2,0 ; Rlyeh" in the body; to which I replied "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
For two of the three categories I mentioned that may be considered positive feedback.
Jerry Pournelle has been making this point for (literally) decades, in his Byte columns and his daybook/blog; he has consciously tried to stay as far behind the curve as possible in choice of text editors.
Cause you're correct: the process of professional writing is by all means the job of editing text. Word processing is so much overkill for it that it's worse than useless.
I write everything I can in vi, myself. These days that's generally vim, but I got my start on Tandy Xenix 1.2 on a TRS-80 Model 16, and that was real, honest-to-ghod vi; inability to backspace over a newline and all.
My first job at SCO[*], in 1990, was to write a vi tutorial. So it's pretty much hardwired into my hands.
[*] Back then, SCO was an acronym for "the Santa Cruz Operation", a respectable software corporation who sold the Xenix and AT&T SVR3.2 UNIX server and desktop OS environments ported to run on PC hardware. (Ahem: SVR3.2 solely for licensing reasons -- internally it was shadowing SVR4, but allegedly AT&T's rapacious licensing folks wanted so much money that SCO couldn't afford to buy the real thing.) Subsequently a bunch of shysters from Utah bought the IP and assets of SCO, renamed themselves the SCO Group, and went collectively insane, suing IBM and Novell and taking a copious, smelly shit all over my resumé in the process. But that's another story ...
At one stage I had a whole lot of Microsoft Word documents that we wanted to convert to marked-up text. How hard could that be.
Well, as Charlie said, there are styles and there is direct formatting. And you can have one on top of the other. Did I mention that there are paragraph and character styles? I think there are page and column ones too, but I forget. And then there's positioning, which can be via the margins and tabs or via the styles. Or both. Or via columns. Or tables.And inline elements which can be positioned relative to other text or to an anchor or the margins or the page itself. So what you see in front of you is the result of a whole lot of interacting commands and there is simply no way to convert it directly to marked-up text. You can approximate it, and put up with text and paragraphs that are out of place or have the wrong formatting, or you can duplicate Microsoft Word itself and call that your markup.
It turned out that the files I had were generated by some OCR program that used all of these techniques to approximate the printed page. I went as far as learning Visual Basic in order to clean up the OCR'ed files a bit internally, but in the end I decided that the only way to do a reasonable job would be to do it manually - and since I wasn't being paid for this I declined.
I like ReST for lots of thing , it reminds me of the informal markup used by all README files , back in the day.
I can read it think about the content without the markup getting in the way. I am also playing with writing a application which will use docutils (and hence ReST) internally to help manage multiple plot lines - but it isn't targetted at Novels, but LARPS.
What I do know of which hasn't been mentioned yet is storylines, which does what you describe Scrivener as doing but is cross platform. In fact the author is one of the developers of wxWidgets . (And I believe his wife is a professional published author -so it probably get some reasonable serious testing.)
The program itself isn't FL/OSS but IIRC it's fileformat is reasonable tractable.
Storylines seems to be the thing currently known as Writers Cafe. I'd be a lot more inclined to use it if the user interface didn't make me want to hit myself in the face with a hammer, repeatedly. (Lots of non-overlapping windows are Not My Friend.)
Org-mode for Emacs is very good indeed, if you're okay with Emacs. It is why I started using Emacs after years of VI. A thing of beauty, indeed.
I hacked my keyboard s.t. ctrl and Meta are to the right/left of the space bar. Which is fine (no RSI and fast), but a pain to set up. Maybe somebody will write an org-mode clone for vi
What do publishers actually do with the text you send them? It seems unlikely that they do anything to require Microsoft directly - maybe they just copy and paste the raw text out?
But yeah, chalk me up as another vim user (editing over scp, cross platform compatibility etc, all very nice). Do you use any interesting plugins or scripts for vim, or just the vanilla version?
I highly recommend a combination of Textmate and Markdown or Multimarkdown (if you need more complex formatting - both are available for free as Textmate packages). Markdown is a very nice, intuitive markup language - it takes 20 mins to learn the basics. It plays nice with Scrivener and is easily convertible to .rtf, HTML and TeX (the Textmate package munges out Memoir class TeX documents, which look very nice indeed). All this thanks to advice my co-blogger Kieran Healy, who has a good piece (oriented towards data-crunching social scientists) on choosing workflow apps - http://www.kieranhealy.org/files/misc/workflow-apps.pdf.
Regarding Emacs RSI: I've remapped my otherwise useless capslock key to be CTRL. (google is your friend. This is one of the first few links). It helps a lot, but I haven't gotten rid of my reflexes to use the real CTRL key yet...
I know Charlie is beyond hope, but for you other geeks reading this, it helps for 1) finding a use for that useless caplsock key and 2) alleviating RSI, especially in the Emacs cabal.
Regarding Emacs RSI: I've remapped my otherwise useless capslock key to be CTRL.
Remapping Capslock is all to the good, and with all due respect to the jwz who showed up here, I do feel it is my duty to point out that emacs would be a wonderful operating system if only it had a decent text editor.
OK, that out of the way, I will never remap keyboards to applications. That's backwards. We all have to adapt to less than optimal arrangements, and applications that fail to do so don't deserve a place on my drive. He said, while whacking the escape key and noting that emacs is actually on his drive, but has never been instantiated.
I've been using Emacs nearly exclusively since 1981. Love at first keystroke. Incremental search! Relatively non-modal. That was the original rms emacs written in ITS TECO, running under the incompatibility package on TOPS-20.
I've used Gosling, and FINE, and MINCE, and others when stuck in deficient environments, but now that GNU emacs runs happily on Windows (which has been true for quite a while now) I just use the real thing. I'd used it for quite a while before I ever encountered a computer with a REAL meta key; I still mostly use ESC by habit. However, in org-mode it's very handy to use the real meta key in combination with shift.
As you say, the keystrokes are somewhere down in the spine. If I get a non-emacs window in front of me accidentally, I'm frequently 4 or 5 commands in before I even notice that it's not doing what I'm saying. Very annoying. Luckily (on Windows) Xkeymacs turns most text editing boxes into Emacs boxes, at least for the commands known to my spine.
I think distributed version control is actually exactly what you need -- you use multiple computers, plus have a network server. Every time you go off with one computer and have to merge back to the others later, that's a branch/merge. And it's much easier to handle with a distributed system. Also just keeping a repository on a thumb drive is very handy, and again works with the distributed systems really elegantly. I spent considerable time evaluating what we're going to use next at work, and am still working on some of them; but I did determine very quickly that I was going to recommend Mercurial instead of Git. Mercurial seems to be more stable, more portable, more approachable, more flexible, and less arcane. And, hey, written in Python! Also, better Windows integration including Visual Studio (which made it a slam-dunk choice for work, but is not relevant to you).
Seems like the movie people like specialized writing packages a lot. Having typed script format on an electric typewriter with tab stops, I can see why :-).
An elegant way to combine Vim and Scrivener is now possible with QuickCursor: http://www.hogbaysoftware.com/products/quickcursor/ . So whenever you you are looking for a "pure" writing experience select text-snippets from scrivener and work from inside Vim.
By the way, even though it's also proprietary mac software StoryMill's timeline view makes writing intertwining time-space-storylines easy and enjoyable.
@45, since we're on the subject of revision control:
darcs is a descendent of arch, where many of the ideas you'll find in the various modern changeset-based revision control systems were devised. We gave the idea of word-based changesets and similar concepts a good thrashing out back in the day (structural changesets for XML was a perennial visitor). The bottom line is that there's plenty of fancy diffs around, but one vitally important component is missing from all of them:
patch
What patch does is really hard to get even close to right, when you consider the need to do something useful with merge conflicts, and while there have been many extensions, wrappers, bad reimplementations, and UI improvements to patch, the basic behaviour has stuck around this long because it's miles better than anything else people have come up with. It's been hammered out over decades of experience to be really, really good at applying changes to source code - and note that it is highly specialised to the needs of Ada-like source code, with its specific style of regular structure.
We don't have anything like that for prose or XML or any other type of document you'd care to name. It's not as simple as saying "use words instead of lines", you need to solve a great many hard problems about the right way to apply imprecise changes (that is, applying the changeset to something other than the source it was computed from). Note that this is the only case where it matters what kind of diff you use. We reached the following conclusions:
Nobody seemed to have the faintest idea how to make a patch-like tool for things other than source code. The few attempts that were around turned out to be grossly inadequate; one might describe them as failed research projects. There is no shortage of alternative diffing tools, but that isn't helpful.
Source code appears to be a special case where this problem is really easy; for everything else it's hard and may be intractable.
In the absence of any better options, patch is vastly superior to handling merges by hand, even when it makes a mess.
If anybody ever did crack the problem, it would be straightforward to extend the revision control system to use the new tools.
Hence, we should stick with diff and patch until somebody spends a research career working out how to do semi-automated merges in things other than source code, and not worry about it for now.
In reply to Charlie at #46: There have been programming languages that use bold face for keywords a long time: Algol-68 is the obvious example. However, due to the realities of the time, they also defined several so-called "stropping conventions" (http://en.wikipedia.org/wiki/Stropping) to represent them with the available input devices. Using upper case, or quotes, or dots, is common.
(oh, commenting seems to fail if javascript is disabled)
Don't be harsh with Mr. David; he's pointing out a gap in your business model. For the past half-century at least the sale of Mss has been a nice little earner for authors of all stripes - see, for example, the unfortunate vicar who burnt this on a bonfire by accident: The manuscript for Shadowmancer, which was a number one bestseller in Britain and the US, selling one million copies in the UK alone, was the "editing" draft on which the author had made amendments in his own hand. It had been valued at £250,000 before it was published last June but an independent bookseller offered Mr Taylor a "six figure sum" for it, weeks after it hit the shelves. A lesser precious working manuscript of Shadowmancer still remains, and was last valued at £40,000.
If, as you seem to suggest, you don't do printouts and scribble on them, you're leaving money on the table.
I spent a lot of the last year and a bit in Scrivener writing a book for O'Reilly, Building Social Web Applications. I tried various tools including Word, Pages TextMate etc. What I liked about Scrivener was the ability to restructure at a whim, it abstracts the filesystem away so that I could concentrate on the content. It handles tables poorly, but it is not expensive and didn't crash once. I did end up back in Word for track changes and then in Acrobat for final edits, but the book would not have been written without Scrivener. There are different tools though for different needs, work is still mainly Word, project notes are in textmate etc. I can't imagine fixating on one tool for everything, as some are recommending. I handled the back up by copying to thumbdrive, time machine and daily rsync to my colo box (actually transmit, applescript and iCal). Enough to make it work and have at least 3 copies less than 24 hours old at anyone point.
ChrisB: I am not a bestseller: my MSs are not worth that much. As working on paper is annoying and space-consuming, and adds about £100-150 to my costs in postage, I try not to do that.
Also, Penguin Group (who own Ace) are finally moving to all-electronic publishing workflow, mailing PDFs and Word files back and forth to streamline their operations. Tor have also gone that way.
Gavin Bell: your workflow sounds remarkably similar to mine (modulo the excursion into Acrobat -- I try to avoid PDFs like the plague, but if I can't, I'm on a Mac; Preview is much nicer than Acrobat as a reader, and if I need to annotate, there's PDFPen).
Didn't know about PDFPen, O'Reilly use PDF as a wysiwyg prior to print, so I was ensuring figures were introduced properly etc. In general I'll use Preview to view PDFs, much lighter.
Authoring workflow moving to all electronic is good, Adam Engst has talked about this a lot on tidbits and at various conferences. eg http://conferences.oreillynet.com/cs/toc/view/e_sess/12260 My whole workflow with O'Reilly was electronic, some fellow authors even use SVN to submit their book.
Though authoring of long texts is one area that no one seems to take seriously, other than the long dead Framemaker etc. Probably more of an issue for collaboratively written documents. I think most authors end up in track changes in word in the end... crashes and all I grew to appreciate some of the functionality.
Thanks for the Scrivener mention Charlie.
We are currently working hard to provide 'Scrivener for Windows' during 2010. You can sign-up to our relevant newsletter here: http://www.literatureandlatte.com/about.html#windows.
All the best, David
Although very outdated and no longer with us, Framemaker was one of the best novel, industrial manual programs available years ago until Adobe bought it and eventually killed it off so that they could replace it with their, I believe it was, Illistrator program. I still use Framemaker on an older machine for longer documents and sometimes manuals. An example, Framemaker was used for Airline mechanics training manuals which included movies for installation how-tos. It also was vross platform using their own MML language markup language. You could also create and insert database information into documents from within databases using the same laguage. Its too bad Adobe didn't try to expand and maintain it instead of viewing it as the competition it couldn't beat.
Joe: Adobe replaced FrameMaker (and PageMaker) with InDesign, a first-rate DTP/Layout package insofar as it promptly ate Quark's lunch. InDesign lacks the authoring side of Frame -- it's a layout tool -- but at layout it excels.
(Not that you'll hear me defending Adobe's decision to kill Frame, which I used a couple of times in my earlier career as a tech author. After vi and custom troff macros it was a breath of fresh air ...)
If you need any help with reST, feel free to ask me (I designed it and wrote most of Docutils).
Love your books. Feels good that you chose my project for the next one.
You're right, I forgot what replaced Framemaker. The authoring is what made Framemaker one of the best (imho) writing apps ever. It was complete enough for any large scale project and still simple enough for fax pages, simple letters, memos etc. I used it for creating inhouse software manuals and my boss at that time was as indecisive about the output as any could be. Thank God changes were so easy to make to the master pages. 300-800 page docs could be changed in no time. Personally, I'm very happy to be able to still use it on my older machine. On eBay, the Mac version is still listed for @$600.
There was a company called WebWorks that created an app that took Frame docs and converted them to web pages. We started using it for our website and was fairly easy to create the doc then convert to the web page. Lift your glass for old days!
Jumping in late here but I have a couple of suggestions regarding editors
1) ted - http://www.nllgg.nl/Ted/ is a basic rtf format word processor/editor. One thing I really like about it is that all the formatting options are hidden away so you just see a plain white page to type on.
2) the academics I know all seem to use lyx which is, I believe, a sort of cutdown front end for LaTeX. Never used it myself as I've never needed a fraction of the features but I've heard good things about it.
PS re: Vi/emacs - I've been using joe for that sort of thing when its a text console ever since I discovered it in some ancient late 1990s linux distro.
Charlie @ 91,
Nice to hear a good word said about Framemaker. For a couple of years in the late '80s and for all of the 90's my professional writing was technical proposals, architectural documents, and technical specs, with loads of diagrams. Frame was the only authoring tool I could find that could handle formatted text, diagrams, and tables, in multiple files, without making me constantly refrib the entire document when I added or changed any part of it. And in that period, in 5 different jobs, I was officially allowed to use Frame on only 1 job, due to "corporate software guidelines" </spit>. Suffice to say that I ignored the guidelines most of the time.