This is a good summary of Leo's history and capabilities. Because this thread has been met with some... criticism I will provide my reaction and some guidance for further posting.
Firstly, this is likely not the thread for criticism of Leo's design decisions. Edward and friends are capable programmers who have worked tirelessly to create something that didn't exist elsewhere. They saw a need and filled it. They made design decisions that were well thought out and completely justified. Obviously each of these decisions (including variable naming) would not be agreeable to all but they didn't care and I don't blame them. It's a waste of energy complaining about design decisions in free open source software, if you don't like it either fix it or write your own. That is the blunt reality. As Edward can recount I came in here ranting, raving and critiquing about every corner of Leo but it was time wasted that could have been put into contributing. I feel much better being a contributor than a detractor. I'm not a great programmer, nor do I have knowledge of every programming tool that has ever existed. Despite these limitations I will herald Leo as one of the best tools to study code (echoing Edward's sentiment). Code folding and static outlines (such as in pydev) are no substitute for Leo's dynamic outlines and nodes. Leo's power and beauty comes from being able to focus on exactly what you want and nothing more. Tree structured nodes are the only logical way to do this completely and absolutely. Clones and hoisting further cement and enhance this concept. If you feel this concept isn't a big deal then Leo might not be the tool for you. The dynamic nature of Leo's outlines and nodes means you can manipulate them programmatically and there are provisions in place to perform these manipulations (buttons, commands, plugins, etc). These are powerful tools that will only be appreciated if you are on board with the utility of dynamic outlines and nodes. There are countless features and capabilities I would like to see built into Leo, but alas I don't have a magic code genie to grant me programming wishes. As a father of three (two teenagers and one 6 month old) with a full time+ job my attitude has become, Leo is what is and I've made peace with the rest. I recommend others without the time to contribute take the same approach. Those with time, focus on making Leo better or writing your own tool. On Tuesday, October 20, 2015 at 12:08:56 PM UTC-4, 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. 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. > > 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. And Leo's clones let you organize > any data as *you *want, even if all folds are collapsed. > > 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. > > So much for the theory. The following also are important in practice: > > - Native scripting in Python > <http://leoeditor.com/tutorial-scripting.html>, with full access to all > of Leo's sources. > - Leo's plugin architecture <http://leoeditor.com/writingPlugins.html>. > - Leo's rst3 command <http://leoeditor.com/rstplugin3.html>, vim, xemacs > and ILeo <http://leoeditor.com/IPythonBridge.html> (IPython > <http://ipython.org/>bridge), and leoBridge > <http://leoeditor.com/leoBridge.html> module. > - Leo's minibuffer commands, borrowed shamelessly from Emacs. > - @test and @suite <http://leoeditor.com/unitTesting.html>: Leo's > outline-oriented unit testing framework. > - @button > <http://leoeditor.com/tutorial-scripting.html#using-button-nodes>: > bringing scripts to data. > - Leo's outline-oriented directives > <http://leoeditor.com/tutorial-basics.html#leo-directives>. > > The invention/discovery of @clean earlier this year completes Leo is some > sense. > > Acknowledgements: Working with Leo's community of Leo's developers and > users has been a great pleasure for over 20 years. My only regret is that > Bernhard Mulder and Bob Fitzwater are no longer with us. Both made > essential contributions. Bob Fitzwater was my mentor. He gently pushed me > to consider design, not just "bit twiddling". Bernhard Mulder contributed > two of the most important elements of Leo: Leo's traversers (generators) > and the original @shadow algorithm. Neither @clean nor the revised > Mulder/Ream > algorithm > <http://leoeditor.com/appendices.html#the-mulder-ream-update-algorithm> > could possibly have happened without him. I miss both these great > thinkers. Both would have been proud of what they helped create. > > A successful software tool is one that was used to do something undreamed > of by its author.' > -- Stephen Johnson > > Leo is a wild success on this score. I foresaw *none *of these > developments 20 years ago: Leo's minibuffer, @button, @test, @auto, > @clean, Leo's plugin architecture, the rst3 command, the Leo bridge and the > IPython bridge. Surely many other features and uses could be added. *None > *of these would have happened without Leo's community of brilliant > people. These features create the Leonine world. Who knows what will be > the result... > > Edward > > P. S. As I write this, I see that @button is nowhere mentioned in Leo's > History Chapter. That's crazy: @button is arguably the most brilliant > scripting idea ever created anywhere. Many thanks to 'e', whoever you > are. I'd like to thank you by name. @button lead directly to @test. > > EKR > -- 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.
