I use Leo every day. It's a great little editor, very stable and with a ton of handy features.
Outlines are a fantastic tool to keep track of the state of a complex project. My .leo files are what keeps me sane when I'm in the middle of a project with a few hundred documents and need to compile a report. I like it that it's local instead of some online service (there are plenty of those, but I would feel remiss if I used them for something that is supposed to be confidential).
Leo is not very polished, it's a programmers tool and I'm ok with that. I tried getting the hang of emacs 'org' mode for a while but the learning curve was just too steep for me. I want my tools to get out of the way rather than that they dictate my whole workflow and Leo is light enough to do that. It's written in Python, you can modifiy it fairly easily. There are some warts (for instance, the export tree to html function is next to useless) but on the whole I'm very grateful that it exists and I would not know of a replacement other than emacs org mode.
If you're into literal programming Leo is very nice for that as well.
True, it's no IDE. It's not in the same space as Eclipse, Intellij and so on. But if you don't actually need a full IDE and you make your outlines in some non-structured editor then give Leo a try, you probably won't regret it.
The superlatives are being laid on a little thick and likely to invite criticism. There are lots of similar features here that have been introduced in other IDEs and environments before.
Arthur here. We designed that screen shot to be as bad as possible! Our goal was to get people to leave the site as quickly as we could and then to ask random strangers about our IDE rather than clicking around for a few minutes and seeing what it offered. Mission accomplished!
Can you explain your reasoning behind that goal? It doesn't seem like something I'd want, but I'm not a great marketer so I'm curious what you'll gain from it.
This looks great to edit the content tree of static site generators. Can it render Markdown files? Is the syntax highlighter aware of Liquid template tags?
I hope that sample screen shot is not supposed to suck me in, is it?
I think it's supposed to give you and idea of what the editor looks like. Do you find that looking at screenshots usually helps you evaluate programming tools?
Is this particular editor suited to a specific language or set of languages?
I guess that answers my question. I guess the reason you can't answer your question for yourself is because you...
I'm having a hard time figuring out what it is that differentiates Leo from everything else. There's a link "Learn why Leo is so special" that goes to a bunch of links, each filled with quotes from random people gushing with praise.
I'm sure it's fine to have so many people liking your product, but I still don't get what Leo actually DOES, or how it's going to help me write better code / organize my time better / make me the most popular guy in the room.
I went to the screencasts page but came away more confused than ever. It looked like he was just cutting/pasting nodes in a tree for arbitrary reasons.
I would like to echo these comments. "Learn why Leo is so special" was especially misleading.
How about a 4-paragraph summary of what Leo actually is, because I poked around the website for several minutes and still have no idea... other than that it's written in Python, which is a plus for me. :-)
The "Learn about Leo in two hours" just links to the documentation, which is conspicuously missing a "What is Leo?" introduction and goes right into commands.
I'm very intrigued by what this project promises, but I'm intrigued by a lot of projects. If I can't get a good idea of what the software even does in 5 minutes, someone has failed. Maybe it's me, but I don't think so.
I love (don't use, but love) editors like this -- that push at some boundaries and rather than having that push be some "side feature" or "addon" -- is the core part of the editor.
> editors like this -- that push at some boundaries and rather than having that push be some "side feature" or "addon"
The problem with this is that it's really, really hard to build a good editor, and when you concentrate on some novel idea the "basic" functionality suffers.
For example, both Vim and Emacs have easily accessed commands for moving cursor by words, sentences, paragraphs and moving to the nearest given character (on top of traditional beginning and end of line, of course). Also for selecting them, copying and pasting, indenting, surrounding and so on, all in 2 to 3 keystrokes. Another example is the multilevel, tree-like, infinite undo of both editors. And many more: mark ring, multilevel "clipboard", registers, very easy to access macros, narrow to region (this one could be Emacs specific, but I doubt there's no Vim plugin for this), search (both literal and regex) and replace (both literal and with expression, incredibly powerful) and so on and on, and that's just built-in purely editing features, not going into integration with other tools or plugins.
I would have migrated to LightTable long ago if it provided at least some of a more advanced, but purely editing oriented features. It doesn't yet, and it will take it long years to get there because of sheer size of a required featureset. And that's still not counting my 3k lines of personal Elisp and some 20k lines of Elisp in installed plugins.
I'm going to give Leo a try, but even if it really is as good as it's web page says I can't see myself migrating to it in the near future. I may use it from time to time for specific tasks, but my daily editing will be done in Emacs; in the worst case I will have to copy&paste bits of text between Emacs and Leo windows if Leo's editing model/core editing functionality sucks enough (I did this with some other editors and I despite copy&paste overhead I was still faster than I'd be staying in the single editor).
We grow attached to our tools. I built a full screen editor somewhere in the 80's, used it until 2005 or so, when I really could no longer justify (to myself) the effort required of keeping it going. I still type 'e filename' or will use its weird set of control keys when I'm not paying attention. And it's almost 9 years now since I stopped using it. So I suspect you'll be back with emacs before the first day is out. But please do look at leo, it has some interesting ideas embedded in it and there may be ways to get emacs to adopt some of those.
Leo is the best implementation of the literate programming method that I've come across to date, and the first time when it all clicked for me.
The problem is, there's still not a really good composable text editing system. I can drop any number of HTML WYSIWYG editors into a web page in five lines of code, but it's really hard to do that with anything but SciTE for code editors, and SciTE is pretty dreadful.
If this existed, we could start building on that widget and have a decent, extensible text editor from the outset, then build on that.
My impression is that it's a neat idea, with some features borrowed from Emacs and others borrowed from Smalltalk and Morphic, but packaged in a single easy to use editor. Which is nice. I'll definitely try it out when I get some free time.
Sadly the author does not explain what he does when manipulating the leo nodes, and it makes it difficult to follow what haopens, which made me abandon the screencasts
I wrote Python in Leo for a few months 7 (?) years ago. The best use case I found was for bug tracking, you could make a URL node to the ticket and then clone all the relevant pieces of code under it to have everything in the same place. The problem is that outlines required sigils in the source code at the time and that makes sharing a repo with somebody else difficult. The other problem is that it's not Vim.
I expect some version of Leo's outline concept to be a banner feature in some IDE in the future. The idea is good but it's execution in Leo is workable but clunky.
I also have this problem when trying out any other text editor. It's actually quite annoying because every other text editor I try is often much better than Vim at everything it does except editing text.
I'm holding out for someone with more time and patience than me to write Vimim.
There's a line on the home page that says "Leo works well with emacs, xemacs, vim, and ipython." And they have a page about using Leo with other programs, which does have some details about Vim and Emacs:
Thanks, I did see that actually. Obviously I'll have to try before having an opinion on how well it works. I did try sublime (an editor I really like) with the vi extension and found that, although support was comprehensive, there were enough differences for me to ultimately give up.
It would be great if you could integrate Vim itself (or any text editor) with Leo, similar to how Vim integrates with Mutt.
In any case, it's worthy of at least a play because it has some very interesting functionality.
The time is ripe for a tool that integrates knowledge management and development with this "linked outline" structure; it's an upgrade over the classical folder-based storage of files.
There have been previous attempts to create integrated editors for semi-structured information both from the software (Code Bubbles) and documentation (Haystack project, Chandler) perspectives. Machines are now powerful enough for them to become useful and responsive (as these environments consume huge amounts of memory).
For such a tool to become widespread though, it will need to be based on user-friendly design, and be able to share content on the web. Evernote and Workflowy come to mind as tools with those properties, but they don't handle code execution; and reactive, live programming tools like jsfiddle don't allow for outline-like structuring.
It would be great if such a tool was also Open Source, but that's unfortunately not a pre-requisite for success; I imagine Google or Apple will be the first to build such development environment, or to buy a start-up that build it and turn it into an standard.
I broadly speaking applaud the idea of breaking code into code-units which are independent of a specific file hierarchy and tagged with meta data; then reassembling them as a pre-compile / pre-run step.
As far as I can understand this is broadly speaking what leo 'nodes' and 'outlines' are.
It could really do with some better examples of usage though.
I'm also a little skeptical in some regards though; I don't see any tests, and 'mixing in' code units like this (using outline scripts) in various places surely means you have tonnes are unexpected side effects when you change the code units?
The way it does that is by making 'clones'. So for example, if you have a long program that you find a bug in then you take the node with the buggy code (usually a few lines, maybe 10's of lines) and you 'clone' that node to the spot where you have your bug report or list of tickets or whatever. You then describe the bug, the fix and modify the code (which will modify the original code as well), or you modify the original code leaving the clone as a 'living pointer' to the code to document the location where the bug was found. You add the unit test as another node right where the bug report lives.
The 'thin' model (where you import external files without actually having them present in your outline) is a variation on this theme, another way of doing it is to have the code present in the outline itself and then to export the code whenever the document gets saved.
Both methods have their pros and cons. The biggest con in my opinion is that leo use is not widespread enough that you can expect to collaborate with someone else like this. That means that if you post your project on github or if you share the code with a fellow coder that all that Leo mark-up is wasted. This also likely does not play nicely with version control but I haven't tried that particular scenario myself (I just dump the whole tree in git or subversion and I work on most of this stuff on my own anyway).
I do too. A little idea I have had is to record the paths of developers through this graph of code units and use this information to cluster similar groups of code. This clustering could then inform the way the UI is rendered. So a developer might be working on a code unit and then because this code unit is highly correlated to a set of other code units, these code units would appear prominently in some kind of navigation menu.
Roger me sidewise, that editor screenshot looks like a Kindernet Exploder window from 1995.
I'm still waiting for the code editor that takes mouse input exclusively (via gazillions of icons, etc) and refuses any keyboard input. Is Leo on the way there?
Outlines are a fantastic tool to keep track of the state of a complex project. My .leo files are what keeps me sane when I'm in the middle of a project with a few hundred documents and need to compile a report. I like it that it's local instead of some online service (there are plenty of those, but I would feel remiss if I used them for something that is supposed to be confidential).
Leo is not very polished, it's a programmers tool and I'm ok with that. I tried getting the hang of emacs 'org' mode for a while but the learning curve was just too steep for me. I want my tools to get out of the way rather than that they dictate my whole workflow and Leo is light enough to do that. It's written in Python, you can modifiy it fairly easily. There are some warts (for instance, the export tree to html function is next to useless) but on the whole I'm very grateful that it exists and I would not know of a replacement other than emacs org mode.
If you're into literal programming Leo is very nice for that as well.
True, it's no IDE. It's not in the same space as Eclipse, Intellij and so on. But if you don't actually need a full IDE and you make your outlines in some non-structured editor then give Leo a try, you probably won't regret it.