Okay, this is what I've got currently. Description: Leo is a pure python, open source outliner, often used as an IDE. As a project manager, it handles all your files, no matter what language(s) you're using. Uniquely, it lets you to organize your projects below the file level, (elsewhere only doable informally with section comments). Using outlines supports thinking & organizing, allowing big/little picture focus shifts. Its great for code study.
Abstract: What are the special, often unique facilities that Leo brings its users, and what advantages do they give? *External files and outline subtrees can be put into correspondence. *It helps to keep code blocks small. *Reorganizing is easy. *Design and coding shifts are easy. *Hard to code tasks can be further decomposed. *Outline structure works as commenting. *Custom, task oriented, side-views. *Outline nodes are data. *Custom, in outline, python macros. *Extendable beyond just text. Additional notes: What are the special, often unique facilities that Leo brings its users, and what advantages do they give? External files and outline subtrees can be put into correspondence. -- Special headlines can be used to designate parts of Leo outlines that correspond to external text files. Such headlines can have files generated from their subtrees by template(s) contained in body text. These templates determine how the file will be assembled from the descendent nodes. Alternatively, other forms of these headlines can read in entire files and dissect them into outlines. It helps to keep code blocks small. -- You are not faced with a vast empty plain of the file that is going to hold all your code, just a small area of body text that usually only has a half page of code. Reorganizing is easy. -- As your understanding grows, where you put things based on what type of task the code blocks are doing changes. Instead of cutting and pasting, changing section comments to reorganize, - just add/rewrite headlines and move the headlines around in the outline pane. The code blocks in the bodies follow right along. Design and coding shifts are easy. -- You are constantly shifting from "I'll need to do these tasks..." to actually write the code for one of those tasks. Use Leo to capture both. Tasks can quickly be given their own headline so they are not forgotten while you get involved coding up one of those tasks. Hard to code tasks can be further decomposed. -- When coding something difficult, perhaps at the edge of our understanding, you have the option of breaking it into sub-tasks, giving them headlines, and coding up the pieces in their body text. Outline structure works as commenting. -- Commenting, never popular to do, often out of sync with the code, is often replaced with "The code is the comment" maxim. Here, the outline itself often shows what is being attempted, and helps you understand those 300 thousand lines of legacy code you've got to get a handle on. Custom, task oriented, side-views. -- Say you've got some debugging to do, or new functionality to add. Only certain parts of the code are going to be relevant. In a regular code editor, you're left jumping all around your file(s) making changes, hoping you haven't missed things or added side effects. Leo lets you clone a portal to any node, and put that into a separate outline view that you can organize as you want to accomplish your task. Any changes you make in these nodes, (or the sub-nodes they brought with them), are made everywhere those nodes appear in you outline, as they are in fact the same nodes. Outline nodes are data. -- One of the big ideas of Leo is that the body text in nodes are data. An analogy can be made to the cells in spreadsheets, here the data is not in a grid, but held in graphs, each node having a parent, possible siblings, and descendents. Leo scripts use a dead simple DOM (Document Object Model) to access all the data in Leo outlines. Examples: p is the presently selected outline node, p.b and p.h are the node's body text and headline and p.v is the underlying data object for the node. Using this, all sorts of transforming, summarizing, and synthesizing scripts can be written in python. Custom, in outline, python macros. -- "@button macroName" in a headline, provides a click-able button that runs the python script placed in the node's body text. This takes you far beyond any macro language when combined with "Outline nodes are data" idea above. Extendable beyond just text. -- You can add additional *user data* (uA's for short) to any node. uA's can be additional text, including references to external resources, or even binary data. Once associated with a node, Leo will save the uA to the .leo file, and restore the uA when you next load the file. uA's persist arbitrary data for plugins or scripts. Leo scripts access uA's with p.v.u. =================================================================================== I'm debating whether to put the "additional notes" section into the abstract. The application states that the abstract will become public if the talk is accepted, so it will probably appear on the website which might help people decide to attend the talk. Then again it might just be too much info and glaze some eyes over, plus, that would be too wordy for the printed program. Perhaps I'll just add a short sentence to expand each point. Tom -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/2Nsv8IWEtoIJ. 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.
