Thanks Edward for this pre-writing. Hopefully we can contribute in a
constructive way. Some comments below.
On 20/10/15 11:08, Edward K. Ream wrote:
This post discusses what I think matters most about Leo. This post
assumes you are an experienced Leo user. It does not try to duplicate
Leo's Tutorial <http://leoeditor.com/tutorial.html>.
This post will be pre-writing for a version that will be posted to
Leo's web site. All comments are welcome.
Leo is a superb tool for understanding, studying and organizing any
kind of complex data, including computer programs.
That's why I think that Leo should be easy to install by "anyone". The
potential benefits of Leo are beyond programmers, computers scientists,
etc. Any writer, teacher, student, anyone who is organizing thought with
writing, including data could be a beneficiary of Leo.
The first great Aha in Leo's history was that webs (literate programs
<https://en.wikipedia.org/wiki/Literate_programming>) are outlines in
disguise. Leo's importers (@auto) make it easy to studying other
people's programs. Leo's always-present outline structure clarifies
overall program structure and makes many kinds of comments unnecessary.
This idea of an always present outline has been key to me for organizing
writings. Some coworkers have found in the past that this helps them
when we're correcting their text. On a sightly off-topic, most of them
are school teachers making their master studies on education. Some of
them were doctors working on writing complex documents. They're good at
what they do, but having not technical expertise on computers (or not
the proper permissions on school and office machines to install their
software, so they weren't unable to continue using Leo)
Leo is a superb browser for code and data. Unlike many other folding
editors, Leo remembers which nodes were expanded when you last saved
an outline. This is surprisingly important.
Agreed. In my own Leo + IPython inspired outliner I use smalltalk image
based persistence to recover the status of all the objects I have being
working on, included but not limited to the outliner status. But going
back to your old visited nodes and continuing exactly where the cursor
was is a great context kicker when you're writing and something I would
like to implement in my outliner.
And Leo's clones let you organize any data as /you /want, even if all
folds are collapsed.
For me this is the most powerful but misunderstood feature of Leo. Most
of the people which compares it with other IDE rant about why Leo
doesn't works more automatically imposing structure, but in Leo you're
in charger. You impose infrastructure.
Leo is a uniquely powerful scripting environment. This power comes
from three sources: Leo's API, Leo's ability to compose scripts from
outlines and Leo's underlying data structure, a Directed Acyclic Graph
<https://en.wikipedia.org/wiki/Directed_acyclic_graph>, the basis for
Leo's clones.
Leo's API consists primarily of *generators*, such as
c.all_positions(), p.self_and_subtree(), etc. and *properties*, such
as p.b, p.h, p.gnx and p.v.u. Leo's API makes it trivial to write
scripts to access or change any node. AFAIK, these capabilities are
unique. Simulating them in vim or Emacs is possible, but so is
simulating Python's capabilities in C...
Afaik, no other scripting environment allows you to compose scripts
from outlines. @file, @clean, @auto, @others and section references
and definitions make this possible. Section references and
definitions are modeled on the noweb
<https://en.wikipedia.org/wiki/Noweb>language, but all of Leo's script
composition features are fully integrated into Leo's outline structure.
Leo's outline nodes have headlines (p.h) and body text (p.b) and
extensible information (p.v.u). Headlines are descriptions
(meta-data) of the data in p.b and p.v.u. Scripts can rapidly
discover and categorize data using metadata. Leo's @ convention for
headlines (@clean, @file, @auto, @html, etc.) show how extensible this
*node typing* is.
For me the second main insight of Leo (besides emergent always present
tree structure on almost any file) was to have a tree that is a
programmable structure that can be understood and changed by any node
inside that tree. I think that Leo brings structure and
self-referentiality to the dumb flat file word. So you can create a tree
from one (or several) files, deconstruct and reconstructut it they way
you want and automatize the way in behaves and talks with the external
world. Previously I had compared Leo with the Smalltalk object in the
sense that it makes for files kind of what Smalltalk makes for objects.
The more I start to focus on interactive writing and going away of the
unix inspired OS world, the more the second insight become important to
me. I didn't need to deconstruct/reconstruct or impose structure over
flat files but to use outlining for structure thought by (interactive)
writing and I need the outline be a fully programable object. That's the
essence of most of my Leo experience and what I'm trying to bridge with
the Pharo Smalltalk world (with the advantage of a fully introspective,
portable and moldable computing and visualization environment)
Thanks for Leo and all the key inspiration it brings. And, as always,
thanks to the Leo community for the food for thought.
Cheers,
Offray
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
