Leo + Python: the ultimate scripting tool: Conclusion

[Edward K. Ream]

> how different would Leo be if the outline were just directories and text
files?  Would it be a set of file utilities and a kind of super-editor?

I'm glad you asked this question.  There are several kinds of replies.  I
suspect point 3 answers your question most directly, but points 1 and 2 seem
like necessary background:

1. Yes, you could simulate the effects I talk about in various ways.
Because directories are hierarchical, one can no doubt simulate almost any
kind of hierarchical operation using files and directories.  Whether that
simulation is easy, safe, powerful and natural is another matter.  It is
vastly easier (and safer) to create, delete and reorganize nodes in Leo
outlines than it would be to do the corresponding operations on files and
directories.

The main topic of my postings has been the happy interaction between Leo
outlines and scripts.  These interactions would not be nearly so strong if
all hierarchies had to simulated via the file system.  I used the term
"momentum" in one of the postings.  Intellectual momentum is really
important, and we don't want to slow that momentum by simulating things
indirectly that can much more easily be done directly.

For example, I presume unit test would typically be organized in folders to
make it possible to create unit tests dynamically.  And yes, you could use
something like grep to organize search and replace operations.  However,
grep is just another wimpy re tool, so the simulation is weak.

2. Leo itself has many file-oriented features.  In particular, Leo provides
a way of associating parts of outlines with so-called "derived files".  Leo
can change derived files based on changes to Leo outlines.  Very
importantly, Leo can do the reverse: Leo can change outlines based on
changes to derived files.

3. I have devoted a _huge_ amount of wondering, over a period of at least 10
years, about whether one could eliminate .leo files entirely, somehow
replacing .leo files with the union of all derived files.  It turns out that
the answer must be "no".  Without going into details, trying to organize
derived files without a .leo file would be like trying to work in an IDE
without a project file.  The analogy isn't exact, but the conclusion is
inescapable: Leo needs .leo files.  Moreover, Leo needs information _not_
contained in derived files in order to make derived files friendly to cvs.
In the 4.0 code base this extra information is the tnodeList attribute of
<v> elements of .leo files.  Finally, it is just plain more convenient to
squirrel away information in an outline than it would be to create separate
files.  In other words, we wouldn't want to give up .leo files even if it
were possible.

In short, there are extremely strong reasons why Leo works the way it does.
If you want more details, look at the detailed design discussions that have
appeared on Leo's SF forums over the past year or so.  I'm always glad to
talk about Leo, so feel free to ask more questions if you like.

Edward

P.S. You question got me thinking along a new and amusing line: .leo files
simulate (in quite a few ways) a file system, with clones, for example,
acting much like shortcuts or links.  Actually, implementing Leo's outline
operations is quite a bit more complex than implementing the core of a
unix-like file system.  I can say this because I've done both.

EKR
--------------------------------------------------------------------
Edward K. Ream   email:  edreamleo at charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------