On Mon, Oct 23, 2017 at 3:01 PM, Terry Brown <terrynbr...@gmail.com> wrote:
Drawers: I don't think this is something Leo needs other than in the > context of importing org mode files. I agree. > And in that context, only an > implementation wholly compatible with org mode makes sense to me. > Imo, either a uA or an in-text representation would be compatible with org mode because the exporter will write the uA in a compatible way back to the org mode file. > > IPython / Jupyter - depending on configuration, this system can let you > move results between multiple languages (Python, R, javascript, etc.), > access cloud storage (AWS etc.) and distributed computation (Spark, > Hadoop, etc.) and so on. I don't think we want to emulate those > features in Leo, I agree. There is no need to emulate "every little thing". I didn't have time earlier today to say this, but the Leo for org-mode/jupyter user documents are not just quick starts. They should point out the various design decisions made by Leo and the other programs, and tell how those decisions affect the feature sets. For example, *everything* in org mode is plain text. This simplifies some things, and makes other things much harder, even impossible. So in org mode drawers *must* be (usually hidden) text. In Leo, the situation is completely different. All Leo has to do is to convert to/from uA's and text when importing and exporting org mode files. Org mode has features that Leo could use, but there is no great urgency to replace todo.py with agenda's, for example. Otoh, agenda's might suggest features to add to todo.py. Org mode doesn't have gnx's, so it is going to have a hard time doing clones. Org mode does have workarounds, including text-based filters, which work pretty well. In short, the "Leo for X programmers" documents will discuss how the overall Leo ecology differs from org mode, jupyter or whatever. The situation may be more complicated for jupyter files. At present, the importer translates everything to nodes. It would likely be more natural to use uA's for many of the .json elements that jupyter uses. I'll be looking to rewrite the importer/exporter to make this happen. > but I think Leo can be a great interface to the > IPython / Jupyter system - I think Leo's tree can be a viable > alternative to the HTML notebook interface, not to mention the power it > brings to Leo users if Leo can use IPython / Jupyter as a computational > resource. I agree completely. > Too bad Ville's not here to opine, would be interesting to > see what he'd say. > Sigh. 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. For more options, visit https://groups.google.com/d/optout.
