On Thu, Sep 3, 2009 at 8:15 AM, Edward K. Ream <[email protected]> wrote:
> > Two later Ahas > I realize that I described the Ahas, but not how they came about. > The first Aha is that browsers do not, and **can not**, know how to > organize my programs. > > It was an incredible piece of luck that I started with MORE as the > prototype of Leo. MORE *does* have a memory, because MORE has > clones. Leo's clones work *exactly* like MORE clones. So the Aha is > this: clones create permanent views of data that can be remembered. > The Aha arose naturally as the result of using clones. After cloning a node, it is natural to put it somewhere else, and that "somewhere else" usually contains other clones. So you could say that any (usually regular) node containing clones becomes a summary (view) of those clones. Alternatively, the reason I made clones was that I had something to do, and I wanted to focus my attention on that something (project). I create a (regular) node to represent the view, and then drag clones to that node. Either way, the result is the same. Once one starts using clones, it seems almost inevitable that they become part of a project-oriented organization of the data in the outline. The cool thing is that a single outline can contain arbitrarily many views of itself. This came directly from MORE. Leo simply borrowed it. It took *years* of using the Python version of Leo before it became > clear that one of Leo's biggest strengths is this: Leo has a rich DOM > (Document Object Model). > The realization that Leo's DOM is what fundamentally distinguishes Leo from all other editors, came within the last year. I knew that there were many things that you can do in Leo that you can't even *think of* in other editors. But the Aha that Leo's DOM is what makes Leo unique happened while I was writing documentation. Edward P.S. The evolution of Leo's DOM itself (as distinct from the Aha that Leo has a DOM) happened something like this: Ever since Leo became a stand-alone program (that is, after Leo no longer depended on MORE), Leo used @root and @file nodes to denote parts of an outline that would generate external files. Later, @thin, @auto, @shadow and @edit nodes appeared. The C versions of Leo did support a DOM, but nothing much happened because there was no easy way to run C scripts from Leo. This all changed radically in late 2001 when the first Python version of Leo appeared. Leo's Python code created an implicit DOM of the outline. Leo's scripting abilities developed slowly. I don't recall when a usable execute-script command first saw the light of day, but I know for sure it was quite some time before e's brilliant suggestion to "bring scripts to data" resulted in @button nodes. These have made a huge difference in Leo's scripting. For example, before @button, Leo had a very clumsy "script find" mechanism, which was made completely obsolete by @button. @button begat @test, and @test nodes typically using headlines to denote data. The result was a notion that @x nodes denote user-defined types. Leo has a *user-extensible* DOM. Bernhard Mulder's suggestion to use positions (iterators) to traverse the tree was another key ingredient in the evolution of Leo's DOM. This allowed Leo's data structure to develop in new directions, culminating in the one-node world. EKR --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
