Why is Leo great?

[Propadovic Nenad]

Hello Ed and everybody,

I'm writing inspired by Eds post "Wanted: students for the Leo Code Academy" of today, but I'm carrying this question with me since, well, February, when I started using Leo, again, after a pause of maybe ten years.

And yes, I recognize that Leo helps me organize my thoughts and code and texts once in a while, but there seems to be a big gap between those who dig it and those who don't, and I seem to be on the don't-dig-side. Not the fact that it can be useful, but the fact that ut can be useful to extents that it has some fanatic fans.

I tried using Leo for tasks that jumped at me, like, translating some code from Perl to Python. I did it by analyzing the (very poor) structure of that code in Leo, and it still took me a week; afterwards I realized I would have been better of, if I had just translated it to Python - command by command - , *without* understanding the structure, and *then* tried to force structure upon it; so decomposing and analyzing seems not be the right method for this kind of task.

Now, again, another task: I'm analyzing some Python code, much better structured. Still, it's quite complex, the state-machine it contains has multiple rather unclear transitions and conditions of changing transitions... Leo helped me only so much, but just the implications of this and that changing value in the code at runtime... is just not yet clear to me. Trying to analyze seems to be less useful than adding log entries to see the runtime values.

So, after seriously trying to use Leo for tasks that came along my way, and finding it nice, but not so useful that I'd say it's indespensable, may I ask: what are you guys using Leo for?

I realize that writing code of the size and quality of Leo itself is a huge task, and would be hard without a good tool; but are there smaller, but also very useful things you can do with Leo, which would be much harder without it?

(Yes, I have read the documentation; not I have not *studied* it).

I'd appreciate examples which *show* me why Leo is great. I really want to love it, honestly. I *tried* to find it extremely useful ten years ago, when I stumbled upon it after reading about the greatness of outlines (articles from Steve Litt). Yet by now I have the impression that it's most useful in a greenfield environment, when you have control of structure, anyway. Being a contractor, hopping from project to project, I almost never do such development.

Thoughts? Answers? I'd really appreciate them.

Regards,

Nenad

[Propadovic Nenad]

... and while I realize that the answer(s) to my question(s) seem to be somewhere near the first page of the homepage, maybe at:
http://leoeditor.com/testimonials.html
yes, I read those, and I trust them; but there's a lot of opinions there, and few examples.
Examples like: I needed to do this little thing, and I did it this way; and that other little thing, and I did it that way.
I don't mean that I'm entitled to this kind of hand-holding; it's more, I think that this would be the kind of information that would draw many more Python programmers, and potentially other programmers to Leo.
Thanx again;
Nenad

[Matt Wilkie]

On Tue, Jul 5, 2016 at 10:46 AM, Propadovic Nenad <nprop...@gmail.com> wrote:

...*show* me why Leo is great. I really want to love it, honestly. I *tried* to find it extremely useful ten years ago,

This sentiment really strikes a chord with me. Thanks for taking the time to share and ask.

I am in a similar boat. I have at times used Leo extensively, enough to the point I have team contributor access on GitHub in spite of my novice programming skills. But, I've also dropped out, almost a year now. For the second time I've stepped out of the stream and back again. ((Hello Usual Suspects! Long time no talk))

My falling out seems to have different cause than yours, on surface anyway. I don't understand the cause well, or at all, but it revolves about or happens in a milieu of confusion. I've never felt completely comfortable in Leo. There's so much I don't understand, or feel I don't understand, and I'm nervous about shooting myself in the foot.

The daily user experience and key interaction is just different enough from prior tools, say Notepad++, that I'm a bit off balance all the time. For programming activities PyScripter is just swifter and smoother, for me. Partly it's the integrated interpreter; and running the code to line X and then interactive exploring the variables and values at run time is great. The ipython bridge kind of filled the same need, but fell apart for me.

I look at the bones and architecture of Leo, see wonderful possibilities, listen to the words of Edward, Terry, Kent, Jacob... and I'm inspired and enthused. Then I pick up the golden chalice, and in my hands it turns dull and leaden. :-/

Sorry, not a very helpful response. I just wanted to let you know you're not alone in yearning. :)

Matt

[Propadovic Nenad]

Sigh :(. But thanx. :)

--
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 leo-editor+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[derwisch]

Am Dienstag, 5. Juli 2016 22:02:21 UTC+2 schrieb Propadovic Nenad:

I don't mean that I'm entitled to this kind of hand-holding; it's more, I think that this would be the kind of information that would draw many more Python programmers, and potentially other programmers to Leo.

Nenad's and Matt's words resonate a lot with me. I feel I could get so much more out of Leo. But there's the occasional task which Leo helps me completing and which I could elaborate on.

I am working as a biostatistician in clinical trials. One (mundane) task is to print horizontal dividers that can be cut like an alphabetic register to keep multiple dividers visible.  Like this:

----------------------------------------------------+
   18.1 Planning                      18.1.1 Primary|
   18.1.1 Primary Endpoint                  Endpoint|
                                    +---------------+
                                    |18.1.2 Analysis|
                                    |           Sets|   <--- This is the next divider
                                    |---------------+
                                    |  18.1.3 Sample|   
                                    |           Size|   <--- Another divider
   etc.                             |---------------+

Pressing the scripted button causes the node and its descendents to be exported to a series of PDF files using Reportlab. The whole project takes less than 200 lines which I'll be happy to share.

Another task is searching log files of SAS program runs (SAS is an archaic language with a PL/1 background, for some reason popular in Pharma) looking for possible problems, and assemble them in a validation protocol. This was realised within Leo with ~120 lines. I could share this too but be prepared for German node names and comments.

I am a shoddy programmer whose first language is not Python, and project of sizes like this are about what I can handle. Sometimes I think about how my work could be immersed in Leo if only I were better at programming, and I can definitely relate to people who are better programmers and who have Leo deeply linked into their daily routines. I think it's important not to get carried away by their enthusiastic comments. Once in a while I forge a leaden chalice for myself, and find it useful.

[Edward K. Ream]

On Tue, Jul 5, 2016 at 12:46 PM, Propadovic Nenad <nprop...@gmail.com> wrote:

 

there seems to be a big gap between those who dig it and those who don't, and I seem to be on the don't-dig-side. Not the fact that it can be useful, but the fact that ut can be useful to extents that it has some fanatic fans.

​Leo isn't for everybody, and that's completely ok with me. 
​

 

I tried using Leo for tasks that jumped at me, like, translating some code from Perl to Python. I did it by analyzing the (very poor) structure of that code in Leo, and it still took me a week; afterwards I realized I would have been better of, if I had just translated it to Python - command by command - , *without* understanding the structure, and *then* tried to force structure upon it; so decomposing and analyzing seems not be the right method for this kind of task.

​Leo can't create structure out of nothing.  ​Your experience is what matters.  Now you know at least one limit of what Leo can do.

 

Now, again, another task: I'm analyzing some Python code, much better structured. Still, it's quite complex, the state-machine it contains has multiple rather unclear transitions and conditions of changing transitions... Leo helped me only so much, but just the implications of this and that changing value in the code at runtime... is just not yet clear to me. Trying to analyze seems to be less useful than adding log entries to see the runtime values.

​This is often true.  I use g.trace often to understand other people's code.  @clean is especially helpful, as is using git.  That way, git diff will show me exactly what I did.​

 
 

So, after seriously trying to use Leo for tasks that came along my way, and finding it nice, but not so useful that I'd say it's indispensable, may I ask: what are you guys using Leo for?

​

I use Leo for understanding code.  And that's about it.
​

I realize that writing code of the size and quality of Leo itself is a huge task, and would be hard without a good tool; but are there smaller, but also very useful things you can do with Leo, which would be much harder without it?

​I'll leave that for others to answer.
​

 

(Yes, I have read the documentation; not I have not *studied* it).

I'd appreciate examples which *show* me why Leo is great.

​You will have to answer for yourself.  It's ok if you don't want to use Leo.

Edward

[Edward K. Ream]

On Tue, Jul 5, 2016 at 3:04 PM, Matt Wilkie <map...@gmail.com> wrote:

I am in a similar boat. I have at times used Leo extensively, enough to the point I have team contributor access on GitHub in spite of my novice programming skills. But, I've also dropped out, almost a year now. For the second time I've stepped out of the stream and back again. ((Hello Usual Suspects! Long time no talk))

​There are two things new in the last year: @clean and the clone-find commands: cfa, cff, cfm, cfmf.​

 

​I'm not sure any of these will be important to you.
​

The ipython bridge kind of filled the same need, but fell apart for me.

​The new jupyter interface may interest you.

EKR

[Edward K. Ream]

On Wed, Jul 6, 2016 at 2:26 AM, derwisch <johannes...@med.uni-heidelberg.de> wrote:

 

Pressing the scripted button causes the node and its descendents to be exported to a series of PDF files using Reportlab. The whole project takes less than 200 lines which I'll be happy to share.

​Yes, Leo scripting is one of its strong point.​

 

 

Another task is searching log files of SAS program runs

​...​

I am a shoddy programmer whose first language is not Python, and project of sizes like this are about what I can handle.

​Imo, the key to handling larger programs is using classes to encapsulate (hide) the data internal to the classes.  With this principle, it doesn't matter how large the program is, or how many classes a program has.  Without this principle, everything can potentially break anything else.  It's almost exactly that simple.
​

 

I think it's important not to get carried away by their enthusiastic comments.

​Again, only you can determine whether Leo's capabilities suit you.

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

For me, Leo is great for its community and for the ideas it embodies. The main one, in my case, is being able to (de)construct thinking with computers by building *emergent programmable outline structure*. It took me years to understand the power of this idea: Any part of a Leo document/tree can be accessed to program the tree itself or anything in Leo. The first time I found this idea with documents was with TeXmacs[a] at the end of 90's, then I found mind maps, but they're not really programmable, and it was really clear to me until I found Leo and used for several years *mostly* for non-programming.

Even if now I don't use python as my primary computer scripting language and I'm more interested in Pharo, live coding, interactive documentation and data activism & visualization, this Leo idea has been pretty influential in the way I write (see [1], in Spanish) and in my research and related prototypes, including Grafoscopio[2], a tool that tries to combine and cross-pollinite ideas of IPtyhon, Leo and Smalltalk.

Tony Hoare (as quoted by Alan Kay in [3], page xvii) says that Algol 60 "was a great improvement, especially on its successors". Now that we're talking about Leo legacy and continuity, I think is important to underline a set of Leo's core ideas, that can be embedded and enriched in other computing environments and tools, besides Leo itself. Of course, as technologist we love our tools (any good craftsman does, because they're deeply related with how and where his making takes form), but sometimes implementation obscures ideas, and we try to see the value of something inside itself, when maybe the best way to find it is by "dislocation", so seeing incarnations of core ideas within different implementations, helps to a better understanding of them and is a way to enrich the legacy.

Thanks for Leo, its community and its ideas,

Offray

Links:

[a] http://texmacs.org/tmweb/home/welcome.en.html
[1] http://mutabit.com/offray/static/blog/output/posts/la-forma-en-que-escribo-para-el-doctorado.html
[2] http://mutabit.com/grafoscopio/index.en.html
[3] https://duckduckgo.com/?q=squeak+learning+programming+with+robots&t=ffsb&ia=products

[Propadovic Nenad]

Hello Ed and everybody,

I'm grateful for your answers and assure you I'll study them.

Special thanks to Johannes, for the description of the "mundane" task he handles with Leo.

Thanks also to Ed and Offray for sharing their views and motivations.

There has been a mention of an important fact in the few answers already: while written in Python and Python-centric, Leo is open to use with and for other programming languages. I was amazed when I realized, some weeks ago, the number of programming languages Leo is instructed to handle.

Dear Ed, I'm not coming from the place of doubting and requesting. I tried to ask the questions, might not be the right questions yet, but I'm looking for them, to understand what's needed to turn Leo in a mass phenomenon. Based on the quality and power of the concepts it implements, it probably should be one. And the one thing that's lacking might be simple words describing this quality and power in ways "my grandmother could understand". Well, maybe not my late grandmother, but my "programming grandmother", the "John Doe"-programmer. OK, I'm aware Leo is not for programmers only, but I picked the one obvious potential "clientele". Maybe even stating who it's for is the first question to answer.

I hope to be back soon with more irritating questions :).

Regards,

Nenad

[Edward K. Ream]

On Wed, Jul 6, 2016 at 11:15 PM, Propadovic Nenad <nprop...@gmail.com> wrote:

 

I was amazed when I realized, some weeks ago, the number of programming languages Leo is instructed to handle.

​Those are the language for which syntax coloring is available.  What's not so well known is that you can write a short @button script that will execute the body text of a node (p.b) as a script in any language.  The script must:

1. Compose the script, using g.getScript as a template.
2. Execute the script (using an external language processor in a separate process), using g.execute_shell_commands.

If you run Leo from a console you should then see the result in the console window.

This is a just a overview, but it should work for most languages.  Few grandmothers will understand this in detail, but perhaps even your grandmother could understand what is possible, if not the details of how :-)

EKR

[Karsten Wolf]

On Tuesday, July 5, 2016 at 7:46:21 PM UTC+2, Propadovic Nenad wrote:

... 

I'd appreciate examples which *show* me why Leo is great. I really want to love it, honestly. I *tried* to find it extremely useful ten years ago, when I stumbled upon it after reading about the greatness of outlines (articles from Steve Litt). Yet by now I have the impression that it's most useful in a greenfield environment, when you have control of structure, anyway. Being a contractor, hopping from project to project, I almost never do such development.

I'm using Leo for about a month now and know the feeling of really having *tried*; my first Leo encounter was with mac-only Leo 1.5 more than 10 years ago.

After rediscovering it my personal Leo success story is a project (python + bottle + bootstrap to replace a Filemaker app) which lay dormant for several month and I was depressed every time I re-started development... it was a mess. The main problem being diverging HTML templates.

After I started unifying my templates with leo using cloned sections so several pieces of every template are identical, overview came back and while the project isn't pure fun it started making a lot of progress in the last two weeks.

Yesterday I changed navigation and I needed to edit only 1 node to make the change for 8 files. It's easy when your html template file looks like this:

@language html

@tabwidth -2

<!DOCTYPE html>

<html lang="de">

  <<std head clone>>

  <body>

    <<std navbar dynamic>>

    @others

    <<std footer>>

    <<bootstrap core javascript>>

  </body>

</html>

and the file structure like this:

Despite the many uses let's not forget the origins of Leo: A literate programming editor.

For me it's the first time I'm *doing* instead of *reading about* literate programming. With real projects. And it's increasing my productivity. And I have to be cautious because Leo is capable of ugly accidents (see: Leo highlights and annoyances as seen from a new user )

And from my POV Literate Programming is still a field without a culture; everybody does something which resembles some aspects of what Knuth wrote about decades ago... but there aren't many agreed on structures and procedures. So we are all dabbling in a 40 year old pioneer field which brought us TeX & Metafont.

That should not be all there is.

[David Szent-Györgyi]

On Friday, July 8, 2016 at 10:26:45 AM UTC-4, Karsten Wolf wrote:

On Tuesday, July 5, 2016 at 7:46:21 PM UTC+2, Propadovic Nenad wrote:

... 

I'd appreciate examples which *show* me why Leo is great. I really want to love it, honestly. I *tried* to find it extremely useful ten years ago, when I stumbled upon it after reading about the greatness of outlines (articles from Steve Litt). Yet by now I have the impression that it's most useful in a greenfield environment, when you have control of structure, anyway. Being a contractor, hopping from project to project, I almost never do such development.

I'm using Leo for about a month now and know the feeling of really having *tried*; my first Leo encounter was with mac-only Leo 1.5 more than 10 years ago.

After rediscovering it my personal Leo success story is a project (python + bottle + bootstrap to replace a Filemaker app) which lay dormant for several month and I was depressed every time I re-started development... it was a mess. The main problem being diverging HTML templates.

After I started unifying my templates with leo using cloned sections so several pieces of every template are identical, overview came back and while the project isn't pure fun it started making a lot of progress in the last two weeks. . . .

Despite the many uses let's not forget the origins of Leo: A literate programming editor.

For me it's the first time I'm *doing* instead of *reading about* literate programming. With real projects. And it's increasing my productivity. And I have to be cautious because Leo is capable of ugly accidents (see: Leo highlights and annoyances as seen from a new user )

And from my POV Literate Programming is still a field without a culture; everybody does something which resembles some aspects of what Knuth wrote about decades ago... but there aren't many agreed on structures and procedures. So we are all dabbling in a 40 year old pioneer field which brought us TeX & Metafont.

That should not be all there is.

I used Leo 4.3 and 4.4 extensively as source code management system and macro processor for writing utility programs in the form of Windows Script Host files.

For those of you unfamiliar with this curious technology of Microsoft's, these files are XML, and a given Windows Script Host file can package multiple scripts in multiple languages as well as resources. Unless special measures are taken, it is necessary to modify the source code of a given script to suit the requirements of XML. I structured the Leo file so that no such modification was required, which made it easy for me to introduce a new script to the outline for me to use when writing a particular utility program. I also figured out how to use Leo to generate multiple Windows Script Host files, each of which could include any or all of the scripts. 

I imagine that reading this would have Edward Ream cringing, because I'm describing a technique he left behind years ago: I used Leo directives that remainin the current source code, though they are deprecated and I do not know that they still work: @root, @tangle, @untangle. These commands are a clear inheritance from Knuth's Literate Programming. I recall Edward writing that they allowed a naive user to corrupt files. I used them with care, as a solitary programmer, and they worked flawlessly for me. 

I was a solitary programmer, working on multiple machines, needing most of all to take my application development environment with me easily, adding to it as I went. Leo 4.3 and 4.4 and Python were extremely easy for me to install on the Windows XP computers I used, because all I needed was: CPython; Python-Win32; Leo; and my .LEO file. Leo 4.3 and 4.4 used the TK toolkit that is part of Python's Batteries Included, and for all the flaws of the release of TK bundled with Python, Edward's painstaking work had it running well, even if it looked plain and the limitations of TK were a drag on his efforts. 

Leo 4.3 and 4.4 gave me a first-rate outliner with clones, and once I put in the effort to build my WSH development environment, Leo took care of the stupid bookkeeping that would clutter my head with useless trivia of the sort that computers can handle perfectly. Add to that the ease of organizing to-do lists and development notes within the outline, and Leo helped me make myself a more effective worker. I don't know that I can offer a praise higher than that. 

In years since, my work life has had me using a Macintosh computer, for which Leo's GUI was not a perfect fit. I am hoping that recent improvements in window management at the MacOS level ease to work with current Leo, using the modern at-commands for file management. I pine for the industrial-strength outliner with clones in Leo! 

My work has me returning to more utility programming on the Windows side, so I hope  to make use of Leo again. I need to figure out whether I can trust the @root/@tangle/@untangle directives that I used with Leo 4.3 and Leo 4.4. 

I need to wrap my head around the more complex requirements for current Leo: Qt and PyQt are required for current Leo, and on the Mac, one is either dealing with Apple's trailing-edge system Python, or a third-party Python and the headaches that represents. 

I need to wrap my head around the modern practice of running code from the development repository. I am not an expert at Git, and I need to dig up and follow the Keep It Simple Stupid recipe. My steadfast commitment to doing my work logged into my computer without Administrator Rights complicates this. 

I don't know that I will be able to come up with a Windows Script Host development environment as simple to use as the scheme I used with Leo 4.3 and 4.4, but I need to try. 

[john lunzer]

Thank you for putting in the time and effort to learn Leo. My story with Leo mirrors Matt Wilkie's to some extent. 

I have contributor access to Leo's GitHub, I think mostly because of the level of complaining I did and Edward just wanted to shut me up (just kidding). I have been a strong proponent of many improvements, but not as strong a contributor sadly. 

Leo is the best outlining editor available, period. Sadly it looks like that will always be the case and nothing else will get close, at least until Edward completely abandons the project and many years pass until somebody else creates something new.

The node/tree structure and @<file> capabilities of Leo is powerful beyond normal human comprehension (I think Edward/Terry/Ville/Jacob only truly understand). The ability to generate files from a collection of tree nodes can be a huge boon to productivity. In it's own way it is also a burden because you're managing something more complex than a wall of text. 

Ctags/Gtags/Etags type source code tagging systems which provide code "overviews" simply are not the same, not matter how nicely they are presented (Eclipse/Visual Studio). They're nice for navigation but they don't give you the control to organize code to your will. I have always said that Leo's greatest strength for me is inflicting arbitrary levels of abstraction on unsuspecting programming languages. 

Part of my day job is to manage a custom job management system written in python which is driven entirely by JSON configuration files. You feed it a JSON file it does some work, pretty simple. Over the course of a month I can generate probably a hundred or more of these JSON files. Leo and active_path plugin gives me the ability to generate these files on demand and give me access to a detailed database of all the work I've done over the past 2 years! Obviously I had to create the tree structure for date/job/data group organization myself, but I can't imagine this being done any better through some automated/pre-structured organization system than how I did it myself. 

I also use Leo to manage Python code and Python projects. As language agnostic as Leo is let nobody be fooled, Python will always be Leo's true love and writing Python code within Leo opens up all of Leo's capabilities. Again, the active_path plugin can be used to quickly import whole projects. I've yet to find a tool that lets me quickly and efficiently dig into Python code as well as Leo can. Whether you use Quick-Find (my recommendation) or clone-find commands (Edward's recommendation) you'll be getting to where you want to get to as quickly as humanly possible. Only grep/ack/ag/pt can search code as faster, but without the structure. 

The most frustrating aspect of Leo for me is that I know there is great power lying hidden and dormant. Because Leo is pure python there is also a strong temptation to try to squeeze that power out of Leo. The truth is, Leo is huge, and no matter how well organized the code is (very well organized because it's written in Leo itself), it will always be just out of grasp for anyone other than fairly adept programmers and even most of them likely will not have the time to tame it fully. That said, I've written before that tools like vim and emacs suffer from the same problem. 

Edward said Leo is not for everyone or for every task (I don't use Leo for everything), this may be true but that simple statement glosses over the truth. Tree/Node text editor's are for everyone. Everyone should have the freedom to organize code/text to their will and rearrange and modify it as easily as possible.

Bottom line, Leo is great, but making it work for you can be a long arduous journey. I think most people do not make it out of the city gates.

[Edward K. Ream]

​​

On Fri, Jul 15, 2016 at 6:55 AM, john lunzer <lun...@gmail.com> wrote:

Leo is the best outlining editor available, period.

​[big snip]

​.

​Thanks for all these kind words, John. 
​

 

The most frustrating aspect of Leo for me is that I know there is great power lying hidden and dormant. Because Leo is pure python there is also a strong temptation to try to squeeze that power out of Leo. The truth is, Leo is huge, and no matter how well organized the code is (very well organized because it's written in Leo itself), it will always be just out of grasp for anyone other than fairly adept programmers and even most of them likely will not have the time to tame it fully. That said, I've written before that tools like vim and emacs suffer from the same problem. 

​tl;dr: ​

 

​Understanding Leo's scripting tutorial all you need to unleash Leo's potential.

​The problem isn't as serious as you make it out, but a big Aha is required so you don't freak out.  The Aha is simply this: you need to know very little about Leo (or Emacs) to make Leo do what you want.

I remember vividly when I got this about Emacs.  Sure, there are a gazillion emacs commands, but they can all be ignored if you like.  Most people just use a few of them.

The same principle can (must!) be applied to Leo.  Yes, Leo's code base is huge, and there are too many plugins for me (or anyone else) to understand in detail.  But that's not important!  Instead, what you can (must!) do to master Leo programming is to master Leo's scripting tutorial. It will take a little work, but many, many people have done so.

Once you understand c, g, p, p.b, p.h, positions and nodes, you can do a lot with the data in your outlines.  That may suffice for most people.

If you want to modify Leo's graphical interface, you must learn pyqt and Leo's body wrapper interface, which is described in the scripting tutorial.  No doubt about it, gui programming is harder, but you use various plugins as your guide.  As always, feel free to ask questions here.

Summary

You don't have to understand Leo's code base in order to write useful scripts.  Instead, just use Leo's scripting tutorial.  Leo's code base is a source of examples. Don't even think about remembering details about it.

Edward

[Matt Wilkie]

Thanks for your story John, it's great, and encouraging.

On Fri, Jul 15, 2016 at 4:55 AM, john lunzer <lun...@gmail.com> wrote:

Edward said Leo is not for everyone or for every task (I don't use Leo for everything), this may be true but that simple statement glosses over the truth. Tree/Node text editor's are for everyone. Everyone should have the freedom to organize code/text to their will and rearrange and modify it as easily as possible.

 I just love this paragraph. :)

Matt

[Edward K. Ream]

​So do I.  Furthermore, everyone should have a tool that knows how to use outlines/DAG's to real problems. Leo's viewrendered plugins, import commands, etc. are a start, but much more is possible.

Edward