On Thu, Sep 14, 2017 at 9:21 AM, Terry Brown <[email protected]> wrote:
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. > I'm no expert. The basis of my interest is that Jupyter is cool, under intense development, and very widely used. 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. > I agree. But while there are challenges there, I think the interface end of the > problem is not the place to start. > I agree. > 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 integration with other systems. > Yes. Emulating jupyter is hopeless because we will never be able to keep up. Leo's jupyter importer is only a first step towards the second route. 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. > That's a great idea. It should be fairly easy to do. Actually, I suspect I've already done it somewhere ;-) 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. > Very interesting. I think your goal is right on target, namely to use Jupyter for as much as possible. 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. > I'm always a big fan of this kind of rapid prototyping. I know from writing the jupyter importer that jupyter notebooks are just json files. So the first question that comes to mind is whether using the jupyter api is really easier than writing json "by hand". Having said that, perhaps you are thinking that using the jupyter api in the prototype is an essential part of the prototype. > Anyway, just thinking aloud, and maybe all "well, duh" for those who've > > thought more about it than I have. > Not at all a "duh" for me. These are great ideas. 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
