3 ms·

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.

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.