6 ms·

(because there is no toplevel comment saying this): it is emacs' org mode on steroids. If you don't like org mode, move along. ...And some of the side effects

by gcbw2 8y ago

(because there is no toplevel comment saying this): it is emacs' org mode on steroids. If you don't like org mode, move along. ...And some of the side effects of the steroids are already showing (e.g. "you can embed html in markdown". Really? So it is now an html renderer with markdown 'shortcuts'?)

jamesrom 8y ago
Markdown has supported inline HTML since conception: https://daringfireball.net/projects/markdown/ https://daringfireball.net/projects/markdown/
jadbox 8y ago
How is it better than orgmode? Which would be better for note taking?
- Skunkleton 8y ago
  OP didn't say better, rather "on steroids". Have you met steroid users?
  - tomcam 8y ago
    Thanks. That is one of the funniest, most offbeat comments I have ever read. It was a snort-milk-out-your-nose kind of laugh.
  - nurettin 8y ago
    I did, they were the more powerful and less durable cousins of chimpanzees.
  - syntaxfree 8y ago
    My favourite term of emphasis is "on manifolds".
- lysium 8y ago
  Cloning, or better: referencing nodes, is a feature I really miss in org-mode. Having both a list of tickets that I worked on and the list of current tickets, all having the same data, for example.
  - csraghunandan 8y ago
    Considering how extensible org-mode is, I wouldnt be surprised if someone added this functionality to org-mode
colordrops 8y ago
org mode is already on steroids. I guess this must be on DMT.
- jasonm23 8y ago
  Then you'd never get anything done and spend hours saying "Wow!"
j88439h84 8y ago
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.
PurpleRamen 8y ago
org-mode (as a community) is way more powerful then leo will ever be. But org-mode (as a fileformat and majormode for this fileformat) is of course limited in the abilities it can offer in comparision to leo, because an app abstracting way the content is always more powerful then the raw content. Anyway, it's not hard to add the missing outline-features that leo offers in a seperate mode. org-agenda and org-brain are already doing something like this. The question is just whether people really want it. Org-mode has a different philosophy from leo in terms of outlines..

by gcbw2 8y ago

jamesrom 8y ago

Markdown has supported inline HTML since conception: https://daringfireball.net/projects/markdown/ https://daringfireball.net/projects/markdown/

jadbox 8y ago

How is it better than orgmode? Which would be better for note taking?

Skunkleton 8y ago
OP didn't say better, rather "on steroids". Have you met steroid users?
- tomcam 8y ago
  Thanks. That is one of the funniest, most offbeat comments I have ever read. It was a snort-milk-out-your-nose kind of laugh.
- nurettin 8y ago
  I did, they were the more powerful and less durable cousins of chimpanzees.
- syntaxfree 8y ago
  My favourite term of emphasis is "on manifolds".
lysium 8y ago
Cloning, or better: referencing nodes, is a feature I really miss in org-mode. Having both a list of tickets that I worked on and the list of current tickets, all having the same data, for example.
- csraghunandan 8y ago
  Considering how extensible org-mode is, I wouldnt be surprised if someone added this functionality to org-mode

colordrops 8y ago

org mode is already on steroids. I guess this must be on DMT.

jasonm23 8y ago
Then you'd never get anything done and spend hours saying "Wow!"

j88439h84 8y ago

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.

PurpleRamen 8y ago

org-mode (as a community) is way more powerful then leo will ever be. But org-mode (as a fileformat and majormode for this fileformat) is of course limited in the abilities it can offer in comparision to leo, because an app abstracting way the content is always more powerful then the raw content. Anyway, it's not hard to add the missing outline-features that leo offers in a seperate mode. org-agenda and org-brain are already doing something like this. The question is just whether people really want it. Org-mode has a different philosophy from leo in terms of outlines..