Text Editor

Most of the tools I use are based on interpreters or compilers that read text files with some markup or commands: this allows me to use a single text editor I'm confortable with, not the one chosen by the developers of said tools. This also allows me to run whatever preprocessors I need on the file. Another advantage is that what an human has written, another human can always read, directly from the source, even when interpreters or compilers are not available, and in an emergency a manual conversion to some new format when the old is no longer availble is always possible, altough time consuming.

My current choice of editor is VIM: I'm quite confortable with the vi workflow, and I like an editor that is well integrated in the *nix style, but offers such useful features as syntax higlighting and indenting. I'm starting to get worried about its bloat and feature creep, however, so I plan to look among other vi clones for a better balance between features and size. Daily using a vi clone has an additional advantage: when stuck with a rawer version of vi such as those available in busybox or under solaris you will suffer a bit less, and you will have a clue even when forced to use things like ed.

Of course, other choices are available: from graphical editors like those found in most desktop environments to simple editors like pico; i would not suggest emacs because it is another bulky integrated suite not quite coherent with the modular *nix style, (and the fact that modern computers are suited to worse bulks is not a valid reason to call it lightweight) but if that is what you're confortable with it will work.

Sometimes that's it: there are things for which a simple text file is enought, either distributed or stored as it is (the right way for mail, newsgroups etc.) or treated with some relatively simple tool like Enscript for printing. While the problems with accented characters I talked about in the first version of this article are no longer an issue, sometimes there is a need for something more powerful or more versatile.

Enscript and other printing tools

When I need to print some text file, I usually use enscript: a program that allows me to give some fancy improvement to otherwise plain txt. It can easily use different fonts, both monospaced and proportional, to ease reading (and optimize paper use) of different kinds of document and its ability to recognise various languages and higlight them makes it the perfect tool to print source codes. I also use it, together with some postprocessing tool, to write scripts that print certain kinds of text that need to be printed always in a similar way, such as lyrics on cd booklets. Another similar tool is a2ps, with similar features but different strenghts and weaknesses.

For advanced pretty printing of software code, with output in different formats including html, tex and ansi escape codes, there is also highlight (informations in english on the highlight wiki).

(X|HT)ML

In the original article I wrote about using simple html for documents that were short enough to be read online, but needed some simple formatting: I no longer use that, just like I no longer write raw html for my websites, but I use tools like sphynx or rest2web to maintain whole websites and their structure from few vim-written html templates.

I've also abandoned DocBook, the only other XML based format I've used, because its verbosity and lack of human readability isn't really justified by the quality of the resulting documents.

reStructuredText

Most of what I write nowdays, is written in reStructuredText: an excellent markup language whose main goals include being human readable and simple. It has been created by python developers, people who know about simplicity and elegance, as a tool for inline documentation of code, but it is an all-purpose markup for documents ranging from the simple to anything short of a book or mathematical article.

A simple reStructuredText document looks like plain text with "conventions", such as *s for emphasis or underlines for section titles and can be simply read in its "source" form, while less trivial ones can be converted to various formats such as html, LaTeX (and then ps/pdf) or even odt. The website management tools I've mentioned above also use reStructuredText as their source markup, allowing greater ease of editing than it could be possible with html, as well as the ability to generate other formats from the same sources.

LaTeX

When I'm writing complex documents that will be printed, my choice is of course LaTeX, as it is The tool that gives professional quality typeset documents with minimal effort.

With LaTeX I can write everything from a short article to a book, but also letters, slides etc. worring only about the contents of the document and marking elementary parts of its structure, knowing that the compiler will then produce a layout of quality as high as can be produced with automatical tools (and still higher than most people who are not professionals will get by hand), will take care to generate tables of contents, figures, etc. as well as cross-references and all that such a document needs. Its great abilities in managing math formulas, even intricated ones, is a very appreciated plus.

It is not an all-purpose tool, as it needs to know the "kind" of document, the "documentclass", it's working on to give its usual excellent results, but the standard classes cover all of the usual stuff, and some other useful class can be found over the internet, usually with excellent quality. Someday I think I'll learn to create new classes, altough I'm afraid that I would need also some additional dtp knowdlege to get good results.

While it is made to generate documents meant for printing, modern packages like hyperref (included in common distributions) allow for some hypertext abilities in the formats that support it (such as pdf), and it's even possible to use latex2html to generate an HTML version of the document, even if it is not as good looking as one could want.

PS and PDF Manipulation

Most of the formats I use can be transformed to a page description format like postscript or PDF; I can then apply further manipulations, such as n-up printing or signature reshuffling of pages using PSUtils or the LaTeX + pdfpages based PDFjam respectively.

PostScript

There are still some tasks that couldn't be easily done with those tools: usually single pages with some very specific layout, such as business cards, forms like character sheets for rpg, or even graph paper in strange formats. I used office for those, but with mixed results, as I had to struggle with its bad habit to meddle with the measurements I tell him and rearrange things the way it feels look better (which is a good thing in a common text document, but not in the kinds of works I needed).

One day, more as a way to spend some time than with real hopes, I gave a try to vim-written postscript and the results were surprisingly good. As I already knew, it is a full programming language, not easy to learn for everyone, but versatile and powerful; what I didn't know is that it isn't hard to begin and write something into and its many printing primitives, as one can expect, make printing even quite complex stuff easy. I would never use it for any text more than a couple of lines long: there are other better tools for that, but for pages with more lines than text is exactly what I needed.

To learn it, I've followed the samples included in the Blue Book, continued with Thinking in postscript and then I'm using the Postscript language reference (red book), the Green Book and other documents like How to use Adobe PostScript language files properly.

Preprocessing tools

One of the most useful preprocessor tool that can be applied to a text document is a spell checker: using one such as ispell or aspell allows to use a single dictionary for all of the languages and formats one is writing into, and it can be also easily switched between different dictionaries for different (human) languages. However, I must admit that here I'm talking more in theory than practice, as spell checking is something that I've always seemed to forget, both with office suites and with *nix style tools, getting quite some hate from the ones who have to proofread my works.

Another useful tool is iconv, used to convert between character encodings; while I always use utf8 (or just ascii) for my documents, some of the PS based tools mentioned above don't support it. Since they do support getting input from stdin, and most of my files use characters available in iso8859-9, this is as simple as:

iconv -f UTF-8 -t ISO_8859-9 $SRC_FILE | $OTHER_TOOL

Spreadsheet substitutes

I've never been an heavy spreadsheet user, but sometimes I need to do some math on sets of numbers and I've found it easier to write a quick script in python, possibly using the csv module to read data.

Other tools

There are lots of other *nix style tools that I haven't tried yet, but could be useful for some task or another that usually would be done with an office suite: some of them I suspect have been outdated, or keep just some very specific use (cough *roff cough), others may still surprise me with unsuspectable usefulness and ease of use. I will update this article as I'll find new tools and techniques.

Further readings

In 1999 Allin Cottrell wrote an interesting article on the subject: Word Processors: Stupid and Inefficient.

Long Term Storage of Electronic Data and Documents is another list of reasons to avoid proprietary word processors.

There is a whole world beyond Word a short blog post on the subject, suggesting the use of reStructuredText.

Writing tools, from 2010 and the more recent (2012) Text Advocacy by Charlie Stross. Yet another writer that doesn't like word processors for his job.