Peter's Blog

Redefining the Impossible

LEO: Literate programmng editor


Discovered LEO and editor with outlining and literate programming features. It is written in Python and has good support for writing python and C/C++ programs as well as java and other niche languages.

It looks interesting to me in that it allows a whole project to be organised in a free-form hierarchy. At the top level can be groups of files, within the files could be groups of related classes, with the classes methods may be grouped and with each method sections of code could be grouped. All groups are expressed as nodes in a tree. When the .leo file is saved it automatically creates the appropriate python files containing the 'flattened' code. This makes better organisation possible.

Thoughts on this:

  • it would make a good basic outliner, ignoring the literate programming features.
  • it has an interesting 'clone' feature which allows sections of the hierarchy to be referenced in multiple places. A simple example, if I have a node that describes someone called 'bill' I could put a reference to the 'Bill' node in a calendar node on his brithday, the christmas node under people to send christmas cards to, my hit list etc. In terms of organising code this has great potential: if I want to describe how a piece of code works, the description can link right in to the code being described, completely independent from the file/class/method structure imposed by the programming language.
  • the files it creates have rather ugly markup added. This is there to support round-trip editing: the code generated can be edited and read back into the outliner. This is a really neat feature, making it possible to do the bulk of coding and tweeking in vim and just the structural organising in the outliner.
  • the nodes in the organiser can reference URL's, making this a useful bookmark organising program. Nodes can reference other LEO files which could be a way to support very large projects.
  • the .leo file format is XML making it parsable etc.
  • LEO has a plugin system and is scriptable in Python: interesting.
  • One of the plugins appears to allow VIM to be used as an editor, although I haven't tried that yet.
  • All the LEO source and documentation is handled by LEO: that has to be some form of endorsement.

I find this interesting, the way that the source code can be embedded in the project documentation, organised in a nice hierarchy etc. The source files are surrounded by nice rich metadata in any way I can think of, no more being limited by the file systems directory hierarchy or the structure imposed by the programming language.


Filed under: leo outliners python vim

4 Comments

Peter Says:

over 4 years ago

Spent the day using it and:

  • it a bit slowly on a 450MHz P2. It spends a number of seconds trying to syntax highlight a single 500-ish line file.
  • it loads the entire project into memory on startup, making it none-too scalable
  • no crashing bugs, seems robust
  • sometime adds tab characters to python files it writes which messes up the indentation. I need to fix this as it is breaking things for me.
  • the @file reading messes up my doxygen formatting.
  • the vim plugin would work at the expense of the feature that allows you to open urls by double-clicking on outliner nodes.
  • didn't find any interesting plugins.
  • the source code is odd for a literate programming project in that it is not usefully commented and the author has some form of RSI problem that makes him choose single character variable names to save painful descriptive typing, something I thought only the C++ STL authors were afflicted with.

In conclusion, for literate programming I'm not sure it would scale to a project of more than 1M or so of source which is essentially a one-man project anyway. I'll try it a little longer.

Peter

Dean Says:

over 4 years ago

Well you have put me off it. BTW do you know who is your most frequent visitor? Is it me?

Peter Says:

over 4 years ago

No, it's googlebot.

Peter

Peter Says:

over 4 years ago

For the reasons given above I am not going to use this for coding projects. It may still be useful as an outliner, although the way it deals with urls in node titles rather than bodies seems wrong to me (I have a feeling it was done this way because it was easier to implement in tk rather than because it was the right thing to do).

Sorry but comments on this post are now closed.