This is an extended response to Kent's comment: > For me, there's a big difference between adjacency of node headlines and > adjacent body editors.
This has turned out to be a longish post, so let me state my conclusions first: 1. Leo's screen organization is good enough, and better than the competition. 2. Light Table (LT) does suggest some useful new Leo commands. The LT demos are disingenuous. Unless one uses nothing but a few short methods, LT is going to run out of real estate quickly. Buying a huge screen won't help, and huge screens create their own problems. For me, screens larger than about 21 inches are uncomfortable. There are two parts to LT: the multiple editors, and the data-flowing debuggers. Both demand large amounts of real estate. The Leonine way is simply much more flexible. A view node is an analog of the *entire* light-table screen. In Leo, one could have *many* light-table screens. Presumably, light-table will allow multiple layers, as an ad-hoc feature. It won't be as useful or convenient as in Leo. The view node contains clones. Each clone represents a node in the light-table screen. Unlike LT, you have Leo's full organizing capabilities available in the view. Unlike LT, the view can easily contain arbitrarily many nodes. Unlike LT, each node can be arbitrarily large. If you need to compare two nodes side-by-side, you can use multiple body panes. Unlike LT, you move between nodes (with the keyboard) in the standard ways. LT nodes float in an unorganized space. LT has several ad-hoc outlines views, but there is no real DOM. ===== Suggestions for Leo There *are* aspects of LT that I want to make part of Leo: 1. Instant call-up of documentation for a method. 2. Instant call-up of callers of a method. 3. Instant call-up of the routines called by a method. This isn't going to take a lot of work. Certainly not $300K's worth ;-) Indeed, these are simply variants of the clone-find-all command. Leo creates a view node, finds the desired nodes, and moves clones of the nodes as children of the view node. With this scheme, there is probably no need simply to get the docstring of a function. There is no real-estate penalty for delivering the entire definition of the function. So Leo should have 3 or 4 (or a dozen?) "node/data gathering" commands. No big deal. 4. The debugging part of light-table is, truly, very cool. Having said that, I do not believe that data flow is the key to debugging. Tracing and single-stepping are more fundamental, at least for the work that I do. Once again, it will (usually) be better to have the debugging info for each method be stored in a separate node. Otherwise, even the biggest screen will be large enough only for toy examples. ===== Conclusions 1. Leo's visual layout is an improvement over all its successors. 2. Light Table invites us to create data-gathering commands for Leo. The natural (and really, the only) way to gather large amounts of data is by creating an outline to hold said data. This is a snap in Leo. 3. LT's data-flowing debugger is a potentially interesting project, but it does not particularly excite me. Edward -- 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.
