Hi,
On 24/03/16 08:13, Edward K. Ream wrote:
On Wednesday, March 23, 2016 at 3:55:18 PM UTC-5, Edward K. Ream wrote:*
> Jupyter is Leo's long-sought rendering engine!*
> Folks, this is an Aha on a par with "webs are outlines in disguise"
This post explains why yesterday /might/ turn out to be the second
most important day in Leo's history. More likely,
export-jupyter-notebook will turn out to be just another cool feature :-)
A day or so ago I remarked to Rebecca that for Leo to become truly
popular (hundreds of downloads a day), some "young hotshot" would have
to talk up Leo. Presumably he or she would be a well-connected "star"
of some kind.
Better integration with Jupyter notebooks makes that scenario more
likely. One can imagine an eminent scientist using Leo to create at
least the documentation part ('markdown' nodes) of Jupyter notebooks.
It is actually quite clumsy to edit markdown nodes on the Jupyter web
page:
- Change the node type from 'Markdown' to 'Raw NBConvert'.
- Make the changes.
- Change the note type back to 'Markdown'.
- Re-render the cell by clicking on the 'run cell, select below' icon.
Editing the node in Leo and exporting the entire .ipynb file might be
automated to be faster than this.
Furthermore, generating html headers automatically in Leo, /based on
outline level/, is a huge advantage. Just as with the rst3 command,
one can reorganize a tree of markdown nodes /without/ changing html
headers. And of course, the tree instantly shows document structure,
something that is /impossible/ in Jupyter notebooks.
Yes editing documentation on IPython/Jupyter is quite clumsy. I also
agree that levels of a tree can be used to structure
interactive/exploratory computing, even beyond headers (as said in [1]
and [2], that one in Spanish): ideas, images, code snippets, data
sources, could become Leo nodes, to be hidden, show, computed according
to different readers and leo trees could be traversed in different ways
to generate different documents. A single tree to rule them all, the
same tree to bring them all (and in the darkness bind them :-P). This is
related with the idea of is called computational narratives and a recent
project/search in the Jupyter community[3], a search that I have been
making myself a little longer ([4] Spanish draft, particularly chapter 3).
[1]
http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html
[2]
http://mutabit.com/offray/static/blog/output/posts/la-forma-en-que-escribo-para-el-doctorado.html
[3]
http://blog.jupyter.org/2015/07/07/project-jupyter-computational-narratives-as-the-engine-of-collaborative-data-science/
[4] http://mutabit.com/repos.fossil/piamed/doc/tip/Libro/libro.pdf
That being said, I think that Leo propose an scape to IPython of the
chains of the REPL, that is beyond what the overrated web interface
offers now (but we could use the web with QtWebKit, as John proposes).
And I mean the overrated web interface for everything. Just compare what
you can do with the DOM of the web in the browser alone, with what you
can do with the DOM of Leo inside Leo alone! More of that in below.
*Summary
*Leo could become wildly popular not because of what Jupyter
integration can do for /Leo's/ users, but because of what Jupyter
integration can do for /IPython/Jupyter/ users.
Having said that, Jupyter offers a huge amount to Leo, including
superior rendering. Imo, we must make it as easy as possible to
render Leo outlines using Jupyter. The export-jupyter-notebook command
is the foundation for these efforts.
Finally, Leo's viewrendered pane treats markdown as reStructuredText.
Supporting markdown fully suddenly has very high priority.
For me the best scenario is having the structuring capabilities of Leo
and the interactivity of IPython at the **same** time, instead of
writing in Leo, then exporting it and then rendering it in Jupyter. I
imagine Leo nodes as markdown/IPython code that can be rendered inside
Leo with the help of QtWebToolkit, so we have the rendering capabilities
of the web/notebook without the constrains of "flat file" thinking. When
you're making exploratory computing in Jupyter/IPython is almost natural
to end with long scrolls of REPL inspired "documents" with the bells and
whistles without any paradigmatic shift (see [5] for one examples of
such scrolls). Leo outlines/DOM offer such paradigmatic shift. In fact I
started my grafoscopio project [6] trying to mix ideas from IPython, Leo
and Pharo/Smalltalk with my own, to have such kind of experience.
[5] http://mutabit.com/repos.fossil/piamed/doc/tip/Afiche/narrativa.png
[6] http://mutabit.com/grafoscopio/index.en.html
This doesn't try to outdo IPython, this tries to empower it by providing
it with Leo's outlining, DOM and scripting capabilities. Each (QTWebkit)
node in Leo could be smartly connected with the same IPython kernel, so
the smart traversing and tagging capabilities of Leo could be used to
render/compute the no longer flat cells of IPython. The things that the
Jupyter community is starting to dream about with the computer
narratives (see [3]) are already closer thanks to Leo.
Cheers,
Offray
--
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.
