Hi,
On 10/01/17 02:55, Edward K. Ream wrote:
[...]
*New directives*
*@jupyter-notebook*: explicitly denotes a notebook. All descendants
are IPython cells. Useful when converting a Leo outline to one or more
Jupyter notebooks.
*@cells*: All descendants are IPython cells.
*@cell*: A single IPython cell.
Within a cell, @language denotes the type of cell.
@language markdown denotes a Jupyter Markdown cell. There probably is
not great need for Jupyter Heading cells: they may come free with
Leo's outline structure.
@language python (or julia, or r, etc) denotes a code cell.
*Behavior*
There is lots of room for experimentation re behavior and rendering.
In general, we want cells to work just like the corresponding Jupyter
cells, but enhanced, when possible, by Leo's outline structure.
For example, the rending of @markdown cells might include the
rendering of all descendant @markdown cells, thereby making Jupyter
Heading cells unnecessary with Leo itself. Otoh, Leo will
"reconstitute" Heading cells when exporting @jupyter-notebook trees.
Seems like a good approach. I would give priority to @cell directive and
interaction with (I)python kernels (maybe via yoton), even if other
@-directives for the notebook are not supported at the beginning. Having
compatibility to import and export Jupyter notebooks is important, but
the core concerns should be interactivity "inside" Leo, by making code
nodes behave like code cells. I imagine some kind of default behavior
that keeps you in the flow. For example I have some @icell (for
interactive cell) and Leo presumes that the contents are python and let
them to be executed with a shortcut and to import the output into the
cell (defining another @language inside the @icell will change the
kernel for the proper language).
Having this @icell talking with the python/ipython kernel, will bring
the core of live coding experience, even if we use the Leo tree for
making other experiments, that are not properly exported to the jupyter
format. For example, I have some Leo scripts to traverse a Leo tree,
ignore "invisible" nodes and export all that to markdown (that was
before the markdown support) to create PDFs with pandoc, all that
without referring to the Jupyter format, just from Leo -> pandoc ->
LaTeX -> PDF, but what I was missing was interactivity on the Leo nodes,
that I have with IPython/Jupyter notebooks.
In summary:
The core experience of Jupyter's literate computing is on weaving, in a
document, prose with "live coding", by providing interactive cells. Such
core experience can be bring to Leo by supporting @icell that, with
proper defaults, would made the content of such Leo node behave like an
IPython/Python "code cell", that can talk with a python kernel (or
others) and import the result back to the node. This open a lot of
possibilities to Leo in the scenario of literate computing, to go even
beyond of what is possible with Jupyter now (without damaging
compatibility with it), using Leo's superior programmable tree format
and capabilities: You can have complete books inside a single tree
(instead of split in several ipynb files and directories), you can
export directly to PDF/LaTeX/HTML, just by traversing the tree with your
own @directives, or you can go back to jupyter notebook format when
needed. For this, what is needed is to give priority to @icell and its
behavior, to combine the best of both worlds: interactivity and a self
referential programmable tree.
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.
