Hi,
Is good to see this plans taking form. Literate computing, i.e.
interactive exploratory computing intertwined with prose, in an
outlining environment has been a long search/interest for me since years
ago and is nice to see it happening in Leo. Grafoscopio is a prototype
of the same ideas for the Pharo ecosystem (no multi language/computing
support yet) and I'm glad in bringing some inspiration back to Leo.
Prototyping has been a better way to express that ideas in this and
other communities.
Thanks for the paper's link, surely it will help with the
crosspollination on outlines for literate computing.
Cheers,
Offray
On 21/01/17 18:03, Edward K. Ream wrote:
On Monday, January 16, 2017 at 5:06:19 AM UTC-6, Edward K. Ream wrote:
I don't think I have ever started a year with such excitement
about Leo.
Just before Christmas I wrote the "Leo in 2017
<https://groups.google.com/forum/#%21topic/leo-editor/K8VHBvMOumc>"
post. All good stuff.
Since then, two great new projects have emerged:#366: Jupyter
cells in Leo <https://github.com/leo-editor/leo-editor/issues/366>
and a new project, #370
<https://github.com/leo-editor/leo-editor/issues/370>.
The 21 present issues
<https://github.com/leo-editor/leo-editor/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3ABug%20-label%3ACan%27tFix%20>
are probably going to take most of this year, or perhaps even longer.
In this post, I'll list my present priorities. This is middle-manager
stuff. Feel free to ignore.
With so much to do, planning is important. Here are my present
choices, in /roughly/ the order that I plan to do them. However, I'll
may do several in parallel.
1. Fix the various importer bugs. These have recently bit me. It would
be unbearable to let them hang around. I am going to re-enable the old
python importer code (using basescanner.py), to see whether the
various recently-reported importer bugs apply to it.
If necessary, I'll eventually rewrite the code one more time, after
studying the pyzo code. But the rewrite is not a big priority. All
that matters for now is that the python importer works, even if it
means using the old code for awhile longer.
2. Add org-mode capabilities to Leo, as described in this paper
<https://www.jstatsoft.org/article/view/v046i03>. Leo can not afford
to lag behind org-mode. Happily, this project should be
straightforward. All changes will likely be confined to
c.executeScript and its helpers. This may involve some additional work
to simulate emacs Babel, but that too should be straightforward.
3. Support .org.leo files. As always, writing such files is much
easier than reading them. There will be a bit of design work so that
org-mode "drawers" (attributes) can round-trip properly with Leo
uA's. We may want to simplify uA's to make this simpler.
4. The big projects. This includes pyzo based auto-completion and
debugging, and jupyter-like cells using the pyzo server architecture.
It may also involve fossil stuff.
*Schedule*
I typically use an "expansion factor" of 4. If something seems like
it might take a week, it may take up to a month. Items 1, 2 and 3 look
like a week each (or less), before expansion. Item 4 is more open
ended. It might take months.
All comments welcome.
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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
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.
