A sprint (real or virtual) about Leo 5.6

[Edward K. Ream]

I'd like to propose a sprint to discuss Leo 5.6. This should happen only after Leo 5.5 final goes out the door. This could be a virtual sprint, conducted entirely on leo-editor or #leo, or an actual sprint, perhaps in Ashland, WI or Superior MN.

There are both design and coding issues to be discussed. The main question is what do we want Leo 5.6 to do, and why.

I am not interested in chasing after org-mode features, unless people really want them. In particular, emulating org-mode tables (including its spreadsheet features) seems like a lot of work.

Several new features do stand out:

- Better integration with .org files, say by supporting .leo.org or org.leo files.
- Replace attrib_edit by p.drawers.
- Support for pyzo's client/server based shell.  It this needed? Do valuespace or python_console plugins suffice? I suspect pyzo's architecture is better, but I'm not sure how much better.

And any other topics you might want to discuss.

Yes, I've declared this to be quiet time, but short comments will be welcome now.

Edward

[Largo84]

One feature of Notepad++ that I would love to see emulated in Leo is auto word completion. Maybe that's already available, but it's not obvious to me where or how to enable it.

Rob........

[Offray Vladimir Luna Cárdenas]

Hi,


On 27/02/17 09:11, Edward K. Ream wrote:

[...]

>
> I am not interested in chasing after org-mode features, unless people
> really want them. In particular, emulating org-mode tables (including
> its spreadsheet features) seems like a lot of work.
>

[...]

I don't think chasing anyone is worthy, but neither look only inside Leo
to look for *inspiration* about what it can be.

> - Support for pyzo's client/server based shell. It this needed? Do
> valuespace or python_console plugins suffice? I suspect pyzo's
> architecture is better, but I'm not sure how much better.
>

Anything that can made Leo interactive (in the sense of IPython,
Jupyter, Mathematica, Smalltalk or OrgMode) to make literate computing
possible in this superb outlining environment will be worthy. This has
been kind of a long advocacy, but I think that the best way to do it is
by prototyping (in my case with Grafoscopio).

Cheers,

Offray

[Edward K. Ream]

On Mon, Feb 27, 2017 at 9:05 AM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

On 27/02/17 09:11, Edward K. Ream wrote:

I am not interested in chasing after org-mode features, unless people really want them. In particular, emulating org-mode tables (including its spreadsheet features) seems like a lot of work

I don't think chasing anyone is worthy, but neither look only inside Leo to look for *inspiration* about what it can be.

​I agree. There is lots of inspiring software out there.

- Support for pyzo's client/server based shell.  It this needed? Do valuespace or python_console plugins suffice? I suspect pyzo's architecture is better, but I'm not sure how much better.

Anything that can made Leo interactive (in the sense of IPython, Jupyter,

​...​

) to make literate computing possible in this superb outlining environment will be worthy. This has been kind of a long advocacy, but I think that the best way to do it is by prototyping (in my case with Grafoscopio).

​Good. We can discuss this further in the sprint.

Edward

[Offray Vladimir Luna Cárdenas]

On 27/02/17 10:59, Edward K. Ream wrote:

On Mon, Feb 27, 2017 at 9:05 AM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

On 27/02/17 09:11, Edward K. Ream wrote:

I am not interested in chasing after org-mode features, unless people really want them. In particular, emulating org-mode tables (including its spreadsheet features) seems like a lot of work

I don't think chasing anyone is worthy, but neither look only inside Leo to look for *inspiration* about what it can be.

​I agree. There is lots of inspiring software out there.

Yes like Mathematica, Smalltalk and Org-Mode ;-P (you replace them by dots in your edit, leaving only Python based interactive technologies, which as narrated by Fernando Perez, look for inspiration in systems like mathematica and other non-python stuff).

- Support for pyzo's client/server based shell.  It this needed? Do valuespace or python_console plugins suffice? I suspect pyzo's architecture is better, but I'm not sure how much better.

Anything that can made Leo interactive (in the sense of IPython, Jupyter,

​...​

) to make literate computing possible in this superb outlining environment will be worthy. This has been kind of a long advocacy, but I think that the best way to do it is by prototyping (in my case with Grafoscopio).

​Good. We can discuss this further in the sprint.

OK.

Offray

[john lunzer]

On Monday, February 27, 2017 at 9:11:08 AM UTC-5, Edward K. Ream wrote:

- Support for pyzo's client/server based shell.  It this needed? Do valuespace or python_console plugins suffice? I suspect pyzo's architecture is better, but I'm not sure how much better.

Edward

If we're looking forward Leo should go with the full client/server based shell. This will facilitate a fully interactive Leo environment. I think anything less would hamper future efforts toward interactivity. This should also help knock out IPython integration issues. Two birds with one (larger) stone.

[Edward K. Ream]

On Tue, Feb 28, 2017 at 6:50 AM, john lunzer <lun...@gmail.com> wrote:

On Monday, February 27, 2017 at 9:11:08 AM UTC-5, Edward K. Ream wrote:

If we're looking forward Leo should go with the full client/server based shell. This will facilitate a fully interactive Leo environment. I think anything less would hamper future efforts toward interactivity. This should also help knock out IPython integration issues. Two birds with one (larger) stone.

​I agree.  I asked the question as part of due diligence.

Edward​

[Offray Vladimir Luna Cárdenas]

Just for curiosity, I wonder if the Babel approach taken by org-mode is client sever [1]. I have the "feeling" is not, but I have not still read the papers.

[1] https://www.jstatsoft.org/article/view/v046i03

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 leo-editor+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Tue, Feb 28, 2017 at 9:35 AM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

Just for curiosity, I wonder if the Babel approach taken by org-mode is client sever [1]. I have the "feeling" is not, but I have not still read the papers.

[1] https://www.jstatsoft.org/article/view/v046i03

​I would consult Babels​ docs, not some academic paper ;-)

Edward

[Offray Vladimir Luna Cárdenas]

Thanks. I will read both ;-).

Offray

[Arjan]

> In particular, emulating org-mode tables (including its spreadsheet features) seems like a lot of work.

I use Leo primarily as an information manager (as well as for writing LaTeX), and I very frequently need to capture some tabular information. For me this would be a central feature for Leo as PIM. (It's actually what kept me from switching from Emacs/OrgMode to Leo for several months. Now I use Leo anyway, but keep larger sections of tabular data in LibreOffice Calc or SQLite, or use some plain text separator in a node body. Both of these workarounds are suboptimal.)

So I'm hoping it's important to others as well, and will turn out to be doable!

In any case, it's very nice to see all the recent activity.

Arjan

[Edward K. Ream]

On Wed, Mar 1, 2017 at 7:39 AM, Arjan <arjan...@gmail.com> wrote:

> In particular, emulating org-mode tables (including its spreadsheet features) seems like a lot of work.

So I'm hoping it's important to others as well, and will turn out to be doable!

​It's certainly doable.  tables.py is a start.

Edward

[john lunzer]

While it would be pretty great to have full auto-reformatting ascii org-mode tables my inclination is that there are higher priority org-mode features that should be tackled first (for example, functionality enabling literate programming).

[Offray Vladimir Luna Cárdenas]

I agree. I'm now making table formating on org-mode and literate computing on Grafoscopio. If I need to prioritize a feature that would attract more diverse users to Leo would be literate computing. That has been our case with Grafoscopio and our Data Week hackathon+workshop[1] have participants from several life venues and disciplines: Jorunalism, philosophy, communication studies, developers, teachers, students, among others. They're more attracted by the interactive data storytelling features that by table formating.

[1] http://mutabit.com/dataweek/

If I would have to choose only one feature to be enabled in Leo 5.6 that would be literate computing (even if is limited "only" to Python).

Cheers,

Offray

[john lunzer]

I think limiting it purely to python would be aiming too low. But even if it was it would likely be easy to extend via native subprocess package or the third-party sh package (one of my favorite packages).

[Offray Vladimir Luna Cárdenas]

Maybe. Aiming Pharo was good enough in my case. Other languages could come after, using similar ideas to the ones in Org, Beaker or Jupyter. The nature of prototyping and refactoring can be different in Python, so I would let people with more experience on it take the final design decision. The core issue would be bringing interactivity, finally, to Leo for 5.6 release, but I don't know much on implementation details.

Cheers,

Offray

[Edward K. Ream]

On Monday, February 27, 2017 at 8:11:08 AM UTC-6, Edward K. Ream wrote:

Several new features do stand out:

- Better integration with .org files, say by supporting .leo.org or org.leo files.

Still important.
 

- Replace attrib_edit by p.drawer.

Ditto. I think a pop-up edit widget showing p.drawer will suffice. The import/export code for .org files should set p.draws. p.drawer will likely be a Python property, using uA's behind the scenes.

New item: Support p.results.  Again, p.results will be a Python property, using uA's behind the scenes.  Unlike p.drawer, results will not necessarily be strings. Any picklable values should be allowed, and possibly versioned sequences of values.

- Support for pyzo's client/server based shell.  It this needed? Do valuespace or python_console plugins suffice?

These seem like the wrong questions.  Simplicity of implementation is a red herring.  What matters is compatibility, especially with the Jupyter server and the IPython qt console.

The qt console page contains several important topics that are not reflected in the sidebar, including security and embedding the qt console in a qt application. As a result, it's quite difficult to find these important words. Not sure whether this is read-the-docs problem or an oversight on the part of the Jupyter project.

None of the embedding options seem perfect. It's not clear what the way forward with IPython/Jupyter compatibility.  Leo already has support for IPython, and recent IPython distros have support for Jupyter, so maybe little or nothing is needed. But it would be cool to support the IPython In/Out nodes mechanism in Leo's body pane, with integrated support for graphics, magics, etc.

Edward

[Edward K. Ream]

On Monday, March 20, 2017 at 8:44:01 AM UTC-5, Edward K. Ream wrote:

New item: Support p.results.  Again, p.results will be a Python property, using uA's behind the scenes.  Unlike p.drawer, results will not necessarily be strings. Any picklable values should be allowed, and possibly versioned sequences of values.

Two more new, related, items:

1. Leo  should support the following extension of the execute-script command.  If there is no text selection, execute-script should use only the code from the present insert point back to the previous @language directive (in the node) and forward to the next @language directive.  In effect, this will make @language directives work like org-mode's #+BEGIN_SRC <language> lines.

2. Following up on this idea, Leo probably should allow arguments to @language, as in org mode. If we actually do this, we are likely going to want much of the org mode arg machinery. Naturally, Leo settings may be able to handle much of the load.

Edward

[Edward K. Ream]

On Monday, March 20, 2017 at 8:44:01 AM UTC-5, Edward K. Ream wrote:

- Add p.drawer and related items

A pop-up edit widget showing p.drawer will suffice. The import/export code for .org files should set p.draws. p.drawer will likely be a Python property, using uA's behind the scenes.

#414 Is the enhancement.  Please discuss there.

Edward

[Edward K. Ream]

On Monday, March 20, 2017 at 9:03:33 AM UTC-5, Edward K. Ream wrote:

Leo  should support the following extension of the execute-script command.  If there is no text selection, execute-script should use only the code from the present insert point back to the previous @language directive (in the node) and forward to the next @language directive.  In effect, this will make @language directives work like org-mode's #+BEGIN_SRC <language> lines.

 
#439 is the new issue.  Please discuss there.

Edward

[Edward K. Ream]

On Monday, March 20, 2017 at 9:03:33 AM UTC-5, Edward K. Ream wrote:

Leo probably should allow arguments to @language, as in org mode. If we actually do this, we are likely going to want much of the org mode arg machinery. Naturally, Leo settings may be able to handle much of the load.

#440 is the new issue.  Please discuss it there.

Edward