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. On Thursday, July 4, 2019 at 6:40:45 PM UTC-4, Edward K. Ream wrote: > > > > On Tue, Jul 2, 2019 at 8:22 PM David Szent-Györgyi <das...@gmail.com > <javascript:>> 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 > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/f0532709-48a5-4a58-a50f-a0924ba1beb1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
