4 ms·

What does Leo have that org doesn't? I use org a lot.

hsitz 8y ago
Clones of headings (nodes) is the main thing, IMO. I'm an org user and don't have any special use for clones, but it is a neat feature. I'm pretty sure that Org overall, though, has many more features than Leo.
BeetleB 8y ago
Mostly the clones feature. The most common use case: If you get a bug report, you can put the bug report, portions of the code related to the bug report (which could be spread over several source code files), any tests and test collateral related to it, all in one tree. When you make changes to the code in that tree, the corresponding source file will get touch. Also, things like "Find all functions that contain some string and put them in a tree" is trivial, and used a lot. These are out of the box. You can then script more advanced stuff in Python. Even though it's all Python, it seems to handle heavy loads well. I once opened all the source code of my project at work (0.5M lines of code). It took a long time to load them the first time (initial conversion into nodes). But once I had them loaded, I could save it as a project and reopen easily. Then searching the whole code base for a string was pretty fast as well. I don't know how well Emacs can handle thousands of files... The literate capability is really trivial as well. If you're coding with Leo, you likely will start using basic literate constructs. It's just natural. But don't read too much into the comparison with org mode. I use org mode and Leo for very different things.
- madmulita 8y ago
  EDIT: never mind, I see the clones are references that can appear in multiple places. Wouldn't narrowed views in org-mode accomplish the same?
  - BeetleB 8y ago
    >Wouldn't narrowed views in org-mode accomplish the same? No. Narrowed views only let you see a subtree. This is about gathering nodes from different parts of the tree and putting views into them under another node. Let me give some detailed examples - starting from some basics. In Leo, if I open a .cpp file, it will make a node out of each function. If I edit any node and hit "Save", it will update the cpp file with the change. In Org mode, you can copy/paste code from an existing .cpp file into an org document, but the two are now distinct. A change in the org file doesn't affect the .cpp file. The best you can do is use tangle/weave - but that would involve a fair amount of work to convert your whole project/file. And probably won't play as well with the rest of your coworkers as Leo will. A trivial example: I've cleaned up many of our .cpp files where we had multiple classes in one file, and the methods were all over the place. Since each method was a node, it was easy for me to group together all methods of each class so they are not scattered around the file. It was absolutely trivial. Now to the bug example. You have a bug you need to explore. You have a Leo project that has all your source code. At the top level, you'll have a node called "Code". Under that, each file will be another node. Under each "file" node you'll have a node for each function. Back at the top level, you have another node called "Tests" - also hierarchically structured by type of test. So now you create another top level node and call it "Bug". You can put in notes (e.g. Bugzilla ID, or copy/paste relevant portion from the bug text here). So now what you do is find all parts of the code that you think are involved in the bug. Make a "clone" of their nodes, and put them under your Bug node. So now those functions appear in two places - under the "Code" node, and under your "Bug" node. A clone is basically a "view". If you edit the text of a cloned node, all of its clones get updated. So you can now happily edit code under the Bug node, knowing that your files are getting updated. You can also clone relevant tests and again put them under the Bug node, and fix your tests. When you're done fixing the bug, just delete the "Bug" node. A simpler example: My work involves some rather large classes that are essentially singletons (i.e. a hack to use global variables without calling them that). This causes headaches. So sometimes I need to know all the possible places in my code base where one of its members is updated. In Leo, with one command, I can tell it to search all the nodes for that string, make clones of them, and put them under a top level node. So now under that node I have all the places the variable is touched. Easy to quickly examine. This really sped up the rate at which I would understand unfamiliar parts of the code. BTW, you can get deeper than the function level. I've often taking a long function and split it up into nodes. So some of my code explorations involve nodes that are parts of functions. It is quite easy to break up a function this way in Leo.

Clones of headings (nodes) is the main thing, IMO. I'm an org user and don't have any special use for clones, but it is a neat feature. I'm pretty sure that Org overall, though, has many more features than Leo.

BeetleB 8y ago

Mostly the clones feature. The most common use case: If you get a bug report, you can put the bug report, portions of the code related to the bug report (which could be spread over several source code files), any tests and test collateral related to it, all in one tree. When you make changes to the code in that tree, the corresponding source file will get touch. Also, things like "Find all functions that contain some string and put them in a tree" is trivial, and used a lot. These are out of the box. You can then script more advanced stuff in Python. Even though it's all Python, it seems to handle heavy loads well. I once opened all the source code of my project at work (0.5M lines of code). It took a long time to load them the first time (initial conversion into nodes). But once I had them loaded, I could save it as a project and reopen easily. Then searching the whole code base for a string was pretty fast as well. I don't know how well Emacs can handle thousands of files... The literate capability is really trivial as well. If you're coding with Leo, you likely will start using basic literate constructs. It's just natural. But don't read too much into the comparison with org mode. I use org mode and Leo for very different things.

madmulita 8y ago
EDIT: never mind, I see the clones are references that can appear in multiple places. Wouldn't narrowed views in org-mode accomplish the same?
- BeetleB 8y ago
  >Wouldn't narrowed views in org-mode accomplish the same? No. Narrowed views only let you see a subtree. This is about gathering nodes from different parts of the tree and putting views into them under another node. Let me give some detailed examples - starting from some basics. In Leo, if I open a .cpp file, it will make a node out of each function. If I edit any node and hit "Save", it will update the cpp file with the change. In Org mode, you can copy/paste code from an existing .cpp file into an org document, but the two are now distinct. A change in the org file doesn't affect the .cpp file. The best you can do is use tangle/weave - but that would involve a fair amount of work to convert your whole project/file. And probably won't play as well with the rest of your coworkers as Leo will. A trivial example: I've cleaned up many of our .cpp files where we had multiple classes in one file, and the methods were all over the place. Since each method was a node, it was easy for me to group together all methods of each class so they are not scattered around the file. It was absolutely trivial. Now to the bug example. You have a bug you need to explore. You have a Leo project that has all your source code. At the top level, you'll have a node called "Code". Under that, each file will be another node. Under each "file" node you'll have a node for each function. Back at the top level, you have another node called "Tests" - also hierarchically structured by type of test. So now you create another top level node and call it "Bug". You can put in notes (e.g. Bugzilla ID, or copy/paste relevant portion from the bug text here). So now what you do is find all parts of the code that you think are involved in the bug. Make a "clone" of their nodes, and put them under your Bug node. So now those functions appear in two places - under the "Code" node, and under your "Bug" node. A clone is basically a "view". If you edit the text of a cloned node, all of its clones get updated. So you can now happily edit code under the Bug node, knowing that your files are getting updated. You can also clone relevant tests and again put them under the Bug node, and fix your tests. When you're done fixing the bug, just delete the "Bug" node. A simpler example: My work involves some rather large classes that are essentially singletons (i.e. a hack to use global variables without calling them that). This causes headaches. So sometimes I need to know all the possible places in my code base where one of its members is updated. In Leo, with one command, I can tell it to search all the nodes for that string, make clones of them, and put them under a top level node. So now under that node I have all the places the variable is touched. Easy to quickly examine. This really sped up the rate at which I would understand unfamiliar parts of the code. BTW, you can get deeper than the function level. I've often taking a long function and split it up into nodes. So some of my code explorations involve nodes that are parts of functions. It is quite easy to break up a function this way in Leo.