On Thu, 14 Sep 2017 06:41:49 -0700 (PDT) "Edward K. Ream" <edream...@gmail.com> wrote:
> Imo, the most important direction for Leo is the best possible > integration with existing programs and tools, such as: > > - The Language Server Protocol. <http://langserver.org/> > - Better emulation of org-mode features > <http://orgmode.org/features.html>, such as agendas and tables. > > These are important directions for Leo, and I'll be working on both. > > But imo the most important long-term direction for Leo is the best > possible integration with the Jupyter <http://jupyter.org/>project. > Jupyter is where the action is, with a talented team of devs and a > budget in the millions of dollars. Leo has features lacking in > Jupyter, and vice versa. Better integration with Jupyter is my top > priority in the coming year. I've thought about this too. I suspect you've studied Jupyter much more than I have so this may be "well, duh" for you, but here's where I'm at currently. Jupyter has cells which have an input and output component, source (text) and result. Different cells can be handled by different languages (R, Python, etc) in the same script, and variables passed between them. Results are saved and can be recalculated on demand. So the leo_edit_pane component would be great for displaying cells because of its source / rendered split approach. A stack of leo_edit_pane components is *visually* a Jupyter notebook. But while there are challenges there, I think the interface end of the problem is not the place to start. I think the first question is - do we want to emulate or copy the Jupyter approach in Leo (as is unavoidably the case with org mode), or do we want to integrate Leo with Jupyter, so that Leo becomes an alternate interface to real Jupyter notebooks. I'm convinced we want to go the second route, that's the only way to get all the power of Jupyter in terms of its integrations with other systems. I know Leo can read, so some degree, Jupyter notebooks, but I'm wondering if we need to back off a step and connect Leo to the "Jupyter kernel" so that reading notebooks, and executing cells and caching results etc. is all done by Jupyter. The big difference here is that when Leo reads a notebook and makes it part of the Leo outline everything's in the Leo system, vs. displaying a Jupyter notebook, but maintaining links back to the Jupyter environment, for cell execution etc. Actual implementation might be some kind of hybrid between reading in to Leo and interacting with Jupyter. As opposed to the other extreme, storing all state in Jupyter and reading it constantly. So, if I was working on Leo / Jupyter integration I'd start by writing a non-Leo Python script that programatically created a Jupyter notebook (using Jupyter libraries) which incorporates at least three languages, say Python, markdown, and R or javascript, renders cells, observes data exchange between languages, etc. From that Jupyter API perspective, I think full featured integration into Leo will be easier. Anyway, just thinking aloud, and maybe all "well, duh" for those who've thought more about it than I have. Cheers -Terry -- 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.
