# Chapter 9: History of Leo

This chapter discusses the history of Leo and tells the essential features of each version. Here are the most important dates in Leo's history:

Contents

- Chapter 9: History of Leo
  - Beginnings
  - Breakthrough
  - Apple and YellowBox
  - Borland C++
  - Discovering Python
  - SourceForge
  - Allowing sentinel lines in derived files
  - Untangling @file is easy!
  - Leo 3.x: Continuous improvement
  - Leo 4.0: Eliminating error 'recovery'
  - Leo 4.1: The debut of gnx's
  - Leo 4.2: Complete at last
  - Leo 4.3 Settings
  - Leo 4.4 The minibuffer and key bindings
  - Leo 4.4.4 Improvements
    - Leo 4.4.1
    - Leo 4.4.2
    - Leo 4.4.3
    - Leo 4.4.4
    - Leo 4.4.5
    - Leo 4.4.7 and Leo 4.4.8

## Beginnings

Leo grew out of my efforts to use Donald Knuth's "CWEB system of Structured documentation." I had known of literate programming since the mid 1980's, but I never understood how to make it work for me. In November 1995 I started thinking about literate programming in earnest. Over the holidays I mused about making literate programs more understandable. In January 1996 the fog of confusion suddenly cleared. I summarized my thinking with the phrase, web are outlines in disguise. I suspected that outline views were the key to literate programming, but many details remained obscure.

## Breakthrough

March 5, 1996, is the most important date in Leo's history. While returning from a day of skiing, I discussed my thoughts with Rebecca. During that conversation I realized that I could use the `MORE` outliner as a prototype for a "literate outliner." I immediately started work on my first literate outline. It quickly became apparent that outlines work: all my old problems with literate programming vanished. The `@others` directive dates from this day. I realized that `MORE`'s outlines could form the basis for Leo's screen design. Rather than opening body text within the outline, as `MORE` does, I decided to use a separate body pane.

I hacked a translator called `M2C` which allowed me to use `MORE` to write real code. I would write code in `MORE`, copy the text to the clipboard in `MORE` format, then run `M2C`, which would tangle the outline into C code. This process was useful, if clumsy. I called the language used in the outline `SWEB`, for simplified `CWEB`. Much later Leo started supporting the noweb language.

## Apple and YellowBox

Throughout 1996 I created a version of Leo on the Macintosh in plain C and the native Mac Toolbox. This was a poor choice; I wasted a huge amount of time programming with these primitive tools. However, this effort convinced me that Leo was a great way to program.

Late in 1997 I wrote a `Print` command to typeset an outline. Printing (Weaving) is supposedly a key feature of literate programming. Imagine my surprise when I realized that such a "beautiful" program listing was almost unintelligible; all the structure inherent in the outline was lost! I saw clearly that typesetting, no matter how well done, is no substitute for explicit structure.

In 1998 I created a version of Leo using Apple's YellowBox environment. Alas, Apple broke its promises to Apple developers. I had to start again.

## Borland C++

I rewrote Leo for Borland C++ starting in May 1999. Borland C++ was much better than CodeWarrior C, but it was still C++. This version of Leo was the first version to use xml as the format of .leo files. The last version of Borland Leo, 3.12 Final went out the door July 17, 2003.

## Discovering Python

I attended the Python conference in early 2001. In May of 2000 I began work on an wxWindows version of Leo. This did not work out, but something good did come from this effort. I spent a lot of time adding Python scripting to the wxWindows code and I became familiar with Python and its internals.

I really started to 'get' Python in September 2001. I wrote the white papers at about this time. Python solved all my programming problems. I rewrote Leo in Python in about two months! For the first time in my career I was no longer anxious while programming; it simply isn't possible to create bad bugs in Python. The Python version of Leo was the first officially OpenSoftware version of Leo. The first functional version of Leo in Python was 0.05 alpha, December 17, 2001.

## SourceForge

I registered the Leo project on SourceForge on March 10, 2003. It is certainly no accident that Leo started a new life shortly thereafter. Prior to SourceForge my interest in Leo had been waning.

## Allowing sentinel lines in derived files

In the summer of 2001 I began to consider using sentinel lines in derived files. Previously I had thought that outline structure must be 'protected' by remaining inside .leo files. Accepting the possibility that sentinels might be corrupted opened vast new design possibilities. In retrospect, problems with sentinel almost never happen, but that wasn't obvious at the time! The result of this design was known at first as `Leo2`. That terminology is extinct. I think of this version as the first version to support `@file` and automatic tangling and untangling.

## Untangling @file is easy!

The biggest surprise in Leo's history was the realization it is much easier to untangle files derived from `@file`. Indeed, `@root` creates all sorts of problems that just disappear when using `@file`. The new Python version of Leo became fully operational in early 2002. It was probably about this time that I chose noweb as Leo's preferred markup language. My decision not to support noweb's escape sequences made Leo's read code much more robust.

## Leo 3.x: Continuous improvement

I spent 2002 taking advantages of Python's tremendous power and safety. Many improvements were at last easy enough to do:

- Nested `@others` directives appeared in 3.2.
- Unicode support started in 3.3.
- @first and @last appeared in 3.7
- @asis and @nosent appeared in 3.8.
- Incremental syntax coloring and incremental undo appeared in 3.9.
- Paul Paterson created Leo's plugin architecture sometime during this period. Plugins have been a driving force in Leo's development because people can change how Leo works without altering Leo's core.
- 3.12 fixed a huge memory leak.
- 3.12 Final, the last 3.x version, appeared July 17, 2003.

## Leo 4.0: Eliminating error 'recovery'

In late 2002 and throughout 2003 I worked on an entirely new file format. 4.0 final went out the door October 17, 2003 after almost a year intense design work trying to improve error recovery scheme used while reading derived files. In the summer of 2003 I realized that orphan and `@ignore`'d nodes must be prohibited in `@file` trees. With this restriction, Leo could finally recreate `@file` trees in outlines using only the information in derived files. This made the read code much more robust, and eliminated all the previous unworkable error recovery schemes. At last Leo was on a completely firm foundation.

## Leo 4.1: The debut of gnx's

Leo first used gnx's (global node indices) as a foolproof way of associating nodes in .leo files with nodes in derived files. At the time, there was still intense discussions about protecting the logical consistency of outlines. `@thin` was later to solve all those problems, but nobody knew that then.

## Leo 4.2: Complete at last

Leo 4.2 Final went out the door September 20, 2004. This surely is one of the most significant dates in Leo's history:

- This marked the end worries about consistency of outlines and derived files: Leo recreates all essential information from thin derived files, so there is nothing left in the .leo file to get out of synch.
- Thin derived files use gnx's extensively. This simplifies the file format and makes thin derived files more cvs friendly.
- A sensational scripting plugin showed how to create script buttons. This has lead to improvements in the Execute Script command and other significant improvements in Unit testing.
- As if this were not enough, 4.2 marked the 'great divide' in Leo's internal data structures. Before 4.2, Leo every node in the outline had its own `vnode`. This was a big performance problem: clone operations had to traverse the entire outline! 4.2 represents clones by sharing subtrees. Changing Leo's fundamental data structures while retaining compatibility with old scripts was engineering work of which the entire Leo community can be proud. Chapter 7: Scripting Leo with Python tells how the position class makes this happen. This was a cooperative effort. Kent Tenney and Bernhard Mulder made absolutely crucial contributions. Kent pointed out that it is a `tnode`, not a `vnode` that must form the root of the shared data. Bernhard showed that iterators are the way to avoid creating huge numbers of positions.

Leo 4.2 marked so many significant changes. I often find it hard to remember what life with Leo was like before it.

## Leo 4.3 Settings

Leo 4.3 corrected many problems with `leoConfig.txt`. Instead, Leo gets settings from one or more `leoSettings.leo files`. This version also introduced a way to changed settings using a settings dialog. However, the settings dialog proved not to be useful (worse, it inhibited design) and the settings dialog was retired in Leo 4.4.

## Leo 4.4 The minibuffer and key bindings

Leo 4.4 was a year-long effort to incorporate an Emacs-style minibuffer and related commands into Leo. Thinking in terms of minibuffer commands frees my thinking. Leo 4.4 also featured many improvements in how keys are bound to commands, including per-pane bindings and user-defined key-binding modes.

Development on long-delayed projects accelerated after 4.4 final went out the door. Recent projects include:

- Controlling syntax coloring with jEdit's xml language-description files. See Chapter 15.
- Support for debugging scripts using external debuggers. See Chapter 16.
- Modifying Leo's vnodes and tnodes so that Leo's data can be used with ZODB. See Chapter 17.
- Using pymacs to write Leo scripts within Emacs. See Chapter 18.
- Using the leoBridge module to embed Leo support in other programs. See Chapter 19.
- Using Leo to run unit tests. See Chapter 20.

## Leo 4.4.4 Improvements

Leo 4.4.1 through 4.4.8 contained many incremental improvements, as documented in Chapters 15 through 21 of this Users Guide.

### Leo 4.4.1

- Supported multiple editors in body pane.
- Added the jEdit_colorizer plugin. See Chapter 15: Controlling Syntax Coloring.
- Added the slideshow plugin.

### Leo 4.4.2

- Added support for myLeoSettings.leo
- The 'Big Reorg' made Leo's vnodes and tnode classes independent of the rest of Leo.
- Added support for ZODB. See Chapter 17: Using ZODB with Leo.
- Added leoPymacs module. See Chapter 18: Leo and Emacs.
- Added the leoOPML, leo_to_rtf and leo_to_html plugins.
- Added outline navigation: typing a letter selects the next outline node that starts with that letter.
- Added autocontract during finds.
- Added new commands and options to make Leo usable without a mouse.
- Added an option sax parser for reading .leo files.

### Leo 4.4.3

- Added support for chapters in Leo's core.
- Added support for zipped .leo files.
- Added the leoBridge module. See Chapter 19: Embedding Leo with the leoBridge Module.
- Removed all gui-dependent code from Leo's core.
- Added better support for the winpdb debugger.
- Added support for @enabled-plugins and @open-with nodes in settings files.

### Leo 4.4.4

- The Great Graph Aha: Outlines don't have to be graphs to represent graphs. This Aha meant that there is no need for a separate 'graph world'.
- Added support for @menus and @buttons trees in settings files.
- Added perfect import of foreign files with @auto nodes.
- Added new commands for resolving cvs conflicts.
- Replaced the jEdit_colorizer plugin with the threading_colorizer plugin.
- Made Leo compatible with jython.
- Added better support for icons in headlines.

### Leo 4.4.5

- Leo now recognizes directives in headlines.
- Added support for @rst-preformat nodes to the rst3 plugin.

### Leo 4.4.7 and Leo 4.4.8

- Added the ILeo, the IPython bridge. See Chapter 21: ILeo - the IPython bridge.
- Added support for translating messages to Leo's log.