Something in the recent conversation with John R created several Ahas: *Aha 1:* There is no need to "invent" a Leonine gui for emacs: org mode's "gui" would suffice.
*Aha 2: *Adding Leonine features to org mode would be a task for an Emacs Champion. *I have no plans to write the required elisp code*. Indeed, it would be a big distraction for me and Leo's other devs. However, I am willing to support such efforts with design suggestions. #1026: Embed Leo in Emacs <https://github.com/leo-editor/leo-editor/issues/1026> has been closed and marked "won't do". I am considering revising and reopening it. The rest of this post is an Engineering Notebook post, discussing how such a thing might be done. It will pre-writing for a revision of #1026. As always with ENB posts, feel free to ignore it. *Overview* Leo's major features are clones, generators, Leonine directives, @<file> directives and the Mulder-Ream update algorithm, @test, etc. It would be good to inject something like c and p into *elisp* scripts. Here are the tasks as I see them: *Support Leonine clones* Imo, there is hardly any reason for this project if the enhanced org mode did not support clones. It would be straightforward to add a "leo-gnx" field to an (org-mode) drawer when creating the node*.* But that's the easy part. Leo's DAG is highly optimized. It is the result of decades of evolution. Supporting clone operations in org mode might take one of several forms: 1. Adding a clone copies the cloned tree to another part of the tree. This has serious performance problems. 2. Create a "shadow dag" representing the entire tree. This would require a substantial revision of all parts of org mode. *Support Leonine generators* Org mode uses filters to "traverse" an org-mode file. In most cases, those filters could "deliver" only one copy of each cloned node. There are many design issues here, and they depend on the representation of clones. *Support @<file> nodes* Org babel is great for code snippets. It does not scale up to entire source files. @clean requires a re-implementation of the Mulder-Ream update algorithm in elisp. That would not be a big deal using difflib.el <https://github.com/dieggsy/difflib.el>. Supporting section references would be another major project. Strictly speaking, it is not essential, but it might as well be done if @file and @clean are supported. *Summary* Embedding Leonine features into org mode would be a huge project. I am, on principle, not going to do it, but I would be happy to support the work of an Emacs Champion willing to take on the project. Org mode already supports the crucial separation of node headlines and bodies. That is, p.h and p.b are (or could be) well defined. This means it would be possible to support "heritable" Leo directives. In fact, org mode probably has something similar. Creating a true DAG of (elisp) nodes would simplify many aspects of the implementation. Keeping this DAG in sync with the visible org-mode pane would be a challenge, but the alternatives are likely much worse. All comments and questions are welcome. 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/aed1ba9b-4471-43ef-b95b-cfcd94388dc7%40googlegroups.com.
