Org Brain

[Matthew Piziak]

I searched for org-brain in this group and I couldn't find any mention, so I thought I'd bring to the group's attention.

In particular, like Leo but unlike vanilla Org, Org Brain supports DAGs. In the default visualization mode it shows all children and parents of a given node, and in tree mode it shows them just like Leo does—as cloned nodes.

Has anyone had the pleasure of using both of them for a significant workflow and having a point of comparison? If so I'd love to hear what you think. If not then I'll try them out myself and report back.

[Matthew Piziak]

I searched for org-brain in this group but I didn't see any results so I thought I'd bring it to the group's attention.

In particular, like Leo but unlike vanilla Org mode, Org Brain supports DAGs. By default it displays all parents and children of the current node, but when viewed as a tree it represents this relationship with clones, just like Leo.

Has anyone had the pleasure of using both for a significant workflow and having a point of comparison? If so I'd love to hear your opinion. If not, I'll probably try to use both myself to see what it's like.

[john lunzer]

Hmm... I saw org-brain but it looked clunky so decided to not try it out, perhaps I judged it too soon.

I watched a video and it does look like it shows "clones", in that you can have the same node referenced in different parts of the tree. 

Without using org-brain but seeing it, and with having used Leo heavily, the main differences appear to be: 

• org-brain does not appear to indicate when something is a clone (things would start to get confusing in larger DAGs with nodes of the same name)
• no explicit babel integration (therefor no ability to generate full code files from DAG)
• no explicit tangle/untangle integration (same inability as above)

It appears as though the target audience for org-brain is specifically mind-mapping, where these features might not be missed. That is likely going to be the differentiator, if you're trying to do mind-mapping, note-organization type tasks it may offer you similar features to what you can find in Leo. It is likely not going to get you any kind of Tree/DAG programming ability. The closest thing you will find to Leo's features with regards to organizing code is outshine; be warned there are no clones, it just offers a tree structure (which is definitely better than nothing at all). 

It's been discussed here before but the way Leo handles "clones" is a cut above the rest: cleanly, transparently, and natively. The cleanliness of their implementation is evident in how broadly and generically they can be used. They remind me a bit of symlinks in the Linux filesystem. 

Emacs and any plugin I've seen thus far lacks a true cloning ability. Though I actually do not think it would be too difficult to implement one's self. Emacs has a feature called "indirect buffers" which is a true cloning ability, but lacking all structure. It likely would not be difficult to do something clever with org, babel, and indirect buffers to create a tree/body view very similar to Leo's. You would be able to tangle, but never untangle (this is also a feature unique to Leo).

[David Szent-Györgyi]

I believe that open source software ought to be guided by the desires of the developers. I also believe that it does no harm to provide feedback in the hope of broadening the goals of those developers. I'm sticking my neck out here, commenting on code and tools that I haven't written and haven't used extensively. I do not wish to disparage work that other people have done and made available, where my own contributions have been less by far. I do not operate with a sense of entitlement to the fruits of the labor of other people. That said, John Lunzer's comments reminded me of observations I have made going back some years. 

On Wednesday, June 26, 2019 at 7:15:24 AM UTC-4, john lunzer wrote:

It's been discussed here before but the way Leo handles "clones" is a cut above the rest: cleanly, transparently, and natively. The cleanliness of their implementation is evident in how broadly and generically they can be used. They remind me a bit of symlinks in the Linux filesystem. 

There's a significant impedance mismatch between the full function made possible by the data structures of Leo and those of other applications. Attempting to shoehorn that full function into other applications that provide limited subsets of that full function is not going to be easy, because that requires working against that mismatch continually. I wonder whether one works against a different mismatch for each application that is to interface with Leo. How does one cope with the multiple mismatches without complicating Leo and thereby making Leo fragile or harder to install and maintain? 

 

Emacs and any plugin I've seen thus far lacks a true cloning ability. Though I actually do not think it would be too difficult to implement one's self. Emacs has a feature called "indirect buffers" which is a true cloning ability, but lacking all structure. It likely would not be difficult to do something clever with org, babel, and indirect buffers to create a tree/body view very similar to Leo's. You would be able to tangle, but never untangle (this is also a feature unique to Leo).

I think often of the engineering choices made by Guido van Rossum in Python's early days; where possible, he chose simpler architecture in order to keep the complexity of Python's implementation to a minimum, and provide a usable approach to a wide domain of problems. The result was a simpler architecture that made use of Python as a "glue" language simpler. For example, the Global Interpreter Lock that simplified the implementation of Python made multi-threading impossible, but did not prevent the use of multi-tasking. 

Leo is a programmable IDE that supports the use of multiple simultaneous editor windows, each of which can manage text in ways that are beyond the capabilities of other software. A great deal of work has gone into the elimination of complication of round-tripping of source code that is part of a Leo outline and is shared with people who don't use Leo. Would it not make sense to make the file on disk the medium of exchange? 

John writes above about clones as comparable to symlinks in one of the filesystems used by Linux. Is that not a significant observation, since file systems have provided multiple sorts of link for decades, and over generations of development, applications have been written to use links?

When was the last work done on building a file system that exposes as files the data and metadata available via Leo's API? Years ago, I read of the development of FUSE, which allows the development of file system code that runs in user space on Linux and macOS; I see reference to similar toolkits for Windows. 

Leo supports headless operation with a null GUI. Would it be simpler for Emacs and other software to manipulate the Leo file through a Leo File System? 

[Edward K. Ream]

On Tue, Jul 2, 2019 at 8:22 PM David Szent-Györgyi <das...@gmail.com> wrote:

There's a significant impedance mismatch between the full function made possible by the data structures of Leo and those of other applications.

I agree.

Attempting to shoehorn that full function into other applications that provide limited subsets of that full function is not going to be easy, because that requires working against that mismatch continually. I wonder whether one works against a different mismatch for each application that is to interface with Leo. How does one cope with the multiple mismatches without complicating Leo and thereby making Leo fragile or harder to install and maintain? 

My main approach is to provide @auto importers.  This is not always a perfect (or even very good) solution.

Emacs and any plugin I've seen thus far lacks a true cloning ability. Though I actually do not think it would be too difficult to implement one's self.

This is an open question.  Not being an emacs user I can only give some of my thoughts.

1. Clones require a unique, invariant id.  In Leo, we call such things gnx's, for Global Node Indices.  It would be straightforward to add this to org mode: just add a gnx field to org "drawers".

2, Adding gnx's to org mode "nodes" makes possible Leonine clones, but does not, by itself, make it easy or natural to simulate Leonine operations such as Leo's generators.  Otoh, org mode uses filters to "find" data.  It's not clear to me what would be the natural way to proceed in org mode.

3. In Leo, all clones are actually the same node (A VNode instance).  In other words, Leo outlines are DAG's underneath the covers, which is a significant/crucial optimization.  The MORE outliner created copies of all cloned nodes, and suffered severe performance problems as a result.  I'm not sure what the performance implications are for org mode.

In short, one could imagine org mode having Leonine clones.  Org mode might then recapitulate significant parts of Leo's history.  Or org mode might find its own way forward.

Edward

[Matthew Piziak]

Thank you for the responses!

Yes, it makes perfect sense that clones require unique invariant IDs, to enable referencing. In Org mode it is possible to enable these though `(require 'org-id)` and thence `(org-map-entries 'org-id-get-create)`.

As for finding entries, libraries like `org-depend` use `org-id` to create rich Org-mode node dependencies. I've tried `org-depend` and found it somewhat clunky and slow so I don't think the foundation is quite there yet.

I think `org-brain` just uses files for each object so it wires together DAGs that way.

What would you recommend for an Emacs user looking to make a partial foray into Leo? Migrate all Org files into Leo outlines and then use emacsclient as the node editor? I tried the other direction, using Leo as a service from Emacs, but the solution in the docs requires Pymacs which to my knowledge is now defunct.

[Edward K. Ream]

On Thu, Jul 4, 2019 at 3:58 PM Matthew Piziak <matthew...@gmail.com> wrote:

Thank you for the responses!

You're welcome.

Yes, it makes perfect sense that clones require unique invariant IDs, to enable referencing. In Org mode it is possible to enable these though `(require 'org-id)` and thence `(org-map-entries 'org-id-get-create)`.

Cool.  I didn't know that.

 

As for finding entries, libraries like `org-depend` use `org-id` to create rich Org-mode node dependencies. I've tried `org-depend` and found it somewhat clunky and slow so I don't think the foundation is quite there yet.

OK.

I think `org-brain` just uses files for each object so it wires together DAGs that way.

That will be slow and clunky.  More importantly, nodes/files could go missing.

What would you recommend for an Emacs user looking to make a partial foray into Leo? Migrate all Org files into Leo outlines and then use emacsclient as the node editor?

I would migrate one file into Leo, using @auto.  Then try Leo's xemacs plugin.  If that doesn't work, you could use emacsclient.

 

I tried the other direction, using Leo as a service from Emacs, but the solution in the docs requires Pymacs which to my knowledge is now defunct.

Defunct? It still exists.  Does it not work for you?

Please let us up to date with your experiences.  Leo needs people fluent in emacs.

Edward

[Matthew Piziak]

I would migrate one file into Leo, using @auto.  Then try Leo's xemacs plugin.  If that doesn't work, you could use emacsclient.

Great, I'll give this a whirl.

Defunct? It still exists.  Does it not work for you?

Probably just a compatibility issue that I haven't understood yet. Following up at https://github.com/leo-editor/leo-editor/issues/1233.

Please let us up to date with your experiences.  Leo needs people fluent in emacs.

Will do!

On Friday, July 5, 2019 at 6:02:21 AM UTC-4, Edward K. Ream wrote: