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" > <https://www.gnu.org/software/emacs/manual/html_node/emacs/Buffer-Convenience.html#Buffer-Convenience> > 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? -- 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/61e60808-040b-42e5-8917-8baad6ed4287%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
