The only extra effort required of the writer is to indicate what parts of the document are meant to be fragments of program code. Typically, we do this using lines of markup before and after the fragments.

We generally make these lines follow the style of the notation that we are using for the document itself. For example, when we use TeX or LaTeX, we have used "\beginCode" and "\endCode". For the XML-based notation DocBook, we once used "<code>" and "</code>", before those tags were added to the standard DocBook notation with a different meaning; currently we are using "<programlisting role='executable'>" and "</programlisting>".

Even the longest of these lines takes little effort to type, but we can usually reduce this typing to a single keystroke by programming our word-processing programs. We have done this for the general-purpose text editor Emacs, and for the XML editor XXE, which acts as a word-processing program for DocBook. These are the programs that we currently use most frequently for lightweight literate programming, but we have also used others, including LyX (a word-processor for LaTeX documents) and OpenOffice Writer (a word-processor that uses an XML-based document format). In each case we make a single key insert both the beginning and ending markup lines and leave the cursor between them, so that we are immediately ready to start typing code.

We find that we are able to write both the exposition and the code at our normal "full speed", or close to it. To switch between exposition and code, we simply touch the "code fragment" key, or click our mouse to jump to an existing code fragment or paragraph of text. The notation and tools get in our way very little, and we can concentrate on writing.

Even when we are in a hurry, we find it natural and easy to enter a few words of commentary with every code fragment, recording thoughts such as what purpose the code is intended to serve or why we designed it the way we did. Later, we go back and revise these brief notes to turn them into more "literate" exposition.

We can predict that sometimes a programmer really won't have time for this revision. We can also predict that many programmers will just not want to bother with it; these will be people who don't like writing documentation or just don't like writing. In either case, the result won't be exposition with the kind of "excellence of style" that Knuth had in mind, but at least it will be a program that is better documented than it would have been.