I think we can go one better ... that is, to be able to put Leo organizer nodes between Jupyter nodes. The organizer nodes could contain Markdown, Rst, @file or @clean trees, or what have you. That would give us the ability to further annotate or adapt jupyter nodes beyond what their authors had in mind.
For jupyter code execution, the execution system would have to be able to ignore non-jupyter nodes, of course. Another thing to bear in mind is that jupyter is an ecosystem that is evolving fast. For example, I wouldn't be surprised if it turned out that most jupyter activity ends up runnng on jupyter Lab. We can't possibly play catch-up with it all. So we'll have to pick and choose thoughtfully. But I strongly support trying to integrate with jupyter rather than to try to re-create its functionality. On Monday, March 26, 2018 at 2:26:25 PM UTC-4, Terry Brown wrote: > > > > > True, fully integrated, support for Jupyter will require a *Jupyter > > > gui > > plugin*. > > > > Well, maybe not. The jupyter.py plugin might just do the following: > > > > - Init one or more jupyter kernels in the background. > > - Enhance the execute-script command so that it passes > > code/expressions to a kernel. > > - Show the result in, say, the VR pane. > > - Define various commands in a Jupyter menu. > > This is very much the directions I lean in for Jupyter integration. > The leo-edit-pane split view could work to represent cell input / > output, but isn't integral, your description above is equally good. > This seems the best route to the full power of whatever the Jupyter > server has to offer. > > 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.
